Integer vs char для свойства записи БД

Question

Скажем, у меня есть таблица с недвижимостью. Каждый листинг может быть либо «Продажа», либо «Аренда». Поэтому я могу сопоставить «For sale» с 0, «Аренда» до 1 и сохранить его как INT в базе данных. Однако было бы гораздо более описательным, если бы я сохранил его как «продажу»/«ренту» в поле типа CHAR. Или я могу сопоставить 0 и 1 - две константы FOR_SALE и FOR_RENT в моей программе. Или используйте символы «S» и «R». Каковы наилучшие методы хранения таких свойств в базе данных с условием, что общее количество опций для одного такого свойства очень мало.

Answer 1

Вы должны использовать символ (1) или INT (в зависимости от количества вариантов) и отобразить значения постоянных строк, таким образом, вы будете экономить пространство и строка будет легко настраивается в будущем :)

Answer 2

PostgreSQL и MySQL support enumerated types, что и есть, что вы говорите, как будто ищите. Единственная проблема с перечисленными типами - переносимость базы данных. Oracle, например, не имеет перечисленных типов, поэтому вместо этого вы должны использовать CHAR. Поэтому, если вы настроены на PostgreSQL, например, нет причин не использовать его функции. Если вам нужна переносимость базы данных, использование CHAR (1) или NUMBER (1) является наиболее эффективным.

Обновление: вы можете использовать таблицу поиска с внешним ключом, как упомянуты другие ответы, но с булевыми значениями, которые не будут меняться, это приведет к излишней сложности. Особенно, если вы считаете, что вам нужно создавать дополнительные классы для них в вашем ORM. Если, однако, вы ожидаете, что диапазон значений для этой колонки/переменной изменится, использование поисковой таблицы - лучший способ.

Answer 3

Я бы сохранил атрибут в списке как int и сделал его внешним ключом в таблице поиска, где вы можете добавить свои описания.

Answer 4

Я бы просто использовал char(1) для такой простой вещи; Я бы также наложил на него ограничение CHECK (если доступно), чтобы дать некоторую меру проверки работоспособности. Добавление дополнительной таблицы для чего-то только с двумя значениями является немного бессмысленным, даже если оно подвешено. Кроме того, S или R в столбце помогут вам при отладке или удалении в базе данных вручную, 1 или 6 будут в значительной степени бессмысленными.

Конечно, если у вас есть значения и не могут придумать разумные мнемонические символы для их представления, тогда подход «int и FK» имеет больше смысла.

Вы можете легко изменить с char(1) на «int и FK», если это когда-либо понадобится.