Отсутствие Oracle небольшого типа данных для столбцов таблицы
Я работаю разработчиком на малочисленной группе разработчиков, и что-то раздражало меня до такой степени, когда, я решил действовать...
Oracle не поддерживает немного типа данных - или действительно что-либо еще, что делает смысл ясным в истинных/ложных сценариях. Не напуганный однако, прежде чем я присоединился к команде, мои предки решили использовать символ (1) поля вместо этого, с помощью определенной буквы для обозначения да / верный. К сожалению, хотя, наше приложение привыкло к людьми во всем мире, и по причинам, которые откровенно игнорируют все мои попытки понимания, используемое значение варьируется посредством локализации.
Да, я действительно знаю, что это совершенно не нужно для значений в бэкенде, который пользователь никогда не видит - однако...
Я заметил, что эта практика, кажется, становится продвинутой в новую разработку, которая кажется мне безумный - таким образом, я думаю о предложении Номер (1,0) для этого вместо этого - 0 рассматриваемый ложью / не, что-либо еще интерпретируемое как верном / да...
Простой вопрос - кто-либо может думать о причине, это могло бы быть плохой идеей?
В то время как мы об этом, кто-либо знает, почему Oracle не поддерживает простой булев тип? Разве это не ЯВНЫЙ пропуск?
Аплодисменты в ожидании,
Martin.
5 ответов
Я предпочитаю char(1), а не number(1), поскольку при разумном выборе символов очевидно, какой символ имеет булево значение.
Конечно, вы должны бороться со всеми различными вариациями, выбрать одну и обеспечить ее использование путем наложения проверочных ограничений на столбцы.
Хотя в вашем случае это, вероятно, уже поздно, генерация схемы из другого инструмента часто решает, по крайней мере, проблему согласованности. Лично я предпочитаю для этой цели hibernate, но это зависит от конкретной ситуации.
И, конечно, это вопиющее упущение. Что еще хуже, в PL/SQL есть boolean, но вы не можете использовать его в операторах SQL.
Используйте CHAR (1) и ограничение, разрешающее только «1» и «0».
...
col CHAR(1),
CONSTRAINT cons_atable_col1 CHECK (col1 IN ('1','0'))
I ' Я не родной английский, поэтому я предпочитаю использовать либо 1 и 0, либо «1» и «0». Использование «Y» и «N» не имеет особого смысла, если вы пишете код не на английском (да, кодирование на родном языке действительно существует). Использование «SI» и «NO» или «S» и «N» не выглядит профессиональным (как и использование имен переменных с помощью букв с диакритическими знаками). Единицы и нули, напротив, довольно стандартны, если вы написали код на C, PHP или JavaScript. В любом случае я всегда добавляю соответствующее ограничение, чтобы запретить использование любого другого символа. Помимо субъективных проблем, я не думаю, что есть заметный прирост производительности при выборе CHAR или NUMBER. Мне немного больше нравятся числа, потому что мне не нужно их цитировать :)
Я согласен, что это вопиющее упущение, но я читал серьезно горячие дискуссии на эту тему на некоторых форумах Oracle; это своего рода религиозный вопрос. Некоторые утверждают, что логические значения относятся к типам данных приложения и не имеют места в ядре базы данных. Честно говоря, я считаю, что это одна из тех вещей, которые мы так долго обходились без этого, что лучше было бы сказать, что это было преднамеренно.
Между прочим, MySQL имеет тип BOOLEAN, но это синоним TINYINT (1), поэтому в конечном итоге он равен 1 и 0; и это нормально, потому что в нем также есть константы ИСТИНА и ЛОЖЬ, которые оцениваются как 1 и 0.
Число (1) не лучше, чем char (1). Особенно, если он будет в дополнение к существующему char (1). Это только добавит путаницы.
FWIW, Oracle во внутренних представлениях (таких как USER_TAB_COLUMNS) использует varchar2 (3) (YES и NO). Не уверен, что здесь они на 100% согласуются.
Вот обсуждение Спросите Тома по этой теме. Дает ориентированный на Oracle взгляд на проблему.
Что касается хранения, char (1) на самом деле немного (без каламбура) более эффективен:
SQL> CREATE TABLE xx (c CHAR(1), n NUMBER);
Table created
SQL> insert into xx values('T', 1);
1 row inserted
SQL> select dump(c), dump(n) from xx;
DUMP(C) DUMP(N)
------------------- -------------
Typ=96 Len=1: 84 Typ=2 Len=2: 193,2