Целое число против символа для свойства записи БД

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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