Там какое-либо преимущество к использованию символа вместо строки для односимвольных значений?
В настоящее время я использую артефакт Hibernate JPA 2.0, но я бы хотел использовать что-то более стандартное
До сих пор нет javax.persistence:persistence-api:jar:2.0 артефакта от Sun / Oracle. Либо используйте полный артефакт javax:javaee-api:jar:6.0, если вы хотите что-то из Sun / Oracle ... или просто придерживайтесь интерфейсов, предоставляемых Hibernate, EclipseLink, OpenJPA и т. Д.
4 ответа
Да, char - правильный тип данных для этого. Общее практическое правило: всегда выбирайте наиболее узкий (наиболее ограничительный) тип данных, возможный в контексте . Это означает, что любые недопустимые (или выходящие за пределы диапазона) данные не будут приняты, если они будут введены случайно, поэтому ваша программа / база данных станут менее подвержены ошибкам.
Рассмотрим это с другой стороны: когда вы хотите использовать целое число значения в коде, создаете ли вы целочисленный массив размером один? Конечно, нет, потому что, хотя он и справился бы со своей задачей, он совершенно не нужен . т.е. Сравните:
int[] value = new int[1] { 123 };
value[0] = 456;
с:
int value = 123;
value = 456;
Первое, как я уверен, вы видите, просто абсурдно. Конечно, это не так очевидно в контексте баз данных (использование примерно так же просто, если вы выберете тип данных string ), но я думаю, что эта аналогия помогает объяснить логику выбора.
Кроме того, когда дело доходит до манипулирования значениями в коде, вы должны обнаружить, что наличие поля в более подходящем типе данных (например, char ]) делает его более простым для подходящего использования в коде.
С точки зрения производительности, я бы не подумал, что использование string приведет к значительным накладным расходам. Хорошо, поэтому он занимает незначительно больше памяти, но это, вероятно, не проблема. Однако я думаю, что другие причины, которые я только что предложил, объясняют, почему вы должны выбрать char .
char ) делает его немного более простым для использования в коде.
С точки зрения производительности, я не могу себе представить, что использование string приведет к значительным накладным расходам. Хорошо, поэтому он занимает незначительно больше памяти, но это, вероятно, не проблема. Однако я думаю, что другие причины, которые я только что предложил, объясняют, почему вы должны выбрать char .
char ) делает его немного более простым для использования в коде.
С точки зрения производительности, я не могу себе представить, что использование string приведет к значительным накладным расходам. Хорошо, поэтому он занимает незначительно больше памяти, но это, вероятно, не проблема. Однако я думаю, что другие причины, которые я только что предложил, объясняют, почему вы должны выбрать char .
A Char and a 1 character String are not going to differ much, performance-wise. The CLR will intern strings for you so that is something to consider (but again I cannot imagine the performance benefits would be significant).
Remember that a programming language is a useful tool as an astraction. Always create useful abstractions. In other words I would define your fields like this:
enum Gender { Male, Female }
class Foo
{
Gender gender;
Char middleInitial;
Boolean indicator;
}
This class is semantically valuable now because the datatypes indicate their use. Always use the right tool for the job.
Строки - это массивы символов, поэтому, если вы не уверены, что вам могут понадобиться свойства / методы, которые идут вместе с массивом (например, функции длины и подстроки) Я бы сказал, придерживайтесь символа, поскольку вы уверены, что это только один символ.
У строкового класса будут накладные расходы. Если у вас есть char, нужно ли вам представлять пустое значение с помощью 0x00 или или какого-либо другого неизвестного индикатора? Будет ли это идти в базу данных или исходить из нее, и какое соглашение вы собираетесь там использовать?
Я обычно предпочитаю для этого enums / bools / native семантику на уровне приложения, переводя из любого требуемого соглашения базы данных и в него. В конце концов, Person.Gender == Female и if (! Person.IsDeceased) {} намного более читабельны и понятны.