Попытка использовать альтернативу битового типа в oracle [duplicate]

Я не владею английским языком, поэтому я склонен использовать либо 1, либо 0, либо 1 и 0. Использование «Y» и «N» имеет мало смысла, если вы не кодируете на английском языке (да, кодировка на родном языке существует). Использование «SI» и «NO» или «S» и «N» не выглядит профессиональным (точно так же, как именование переменных с акцентированными буквами). Напротив, ноты и ноль довольно стандартизированы, если вы закодированы в C, PHP или JavaScript. В любом случае, я всегда добавляю соответствующее ограничение, чтобы запретить любой другой символ. Помимо субъективных проблем, я не думаю, что при выборе CHAR или NUMBER заметно увеличение производительности. Мне нравятся номера немного больше, потому что мне не нужно их процитировать:)

Я согласен, что это вопиющее упущение, но я читал серьезно горячие дискуссии по этому вопросу на некоторых форумах Oracle; это своего рода религиозная проблема. Некоторые утверждают, что булевы относятся к типам данных приложения и не имеют места в ядре базы данных. Честно говоря, я считаю, что это один из тех, кого мы так долго не знали, что мы лучше говорили, что это было по назначению.

Кстати, у MySQL есть тип BOOLEAN, но это синоним TINYINT (1 ), поэтому он в конечном итоге равен 1 и 0; что хорошо, потому что он также имеет константы TRUE и FALSE, которые оценивают 1 и 0.

https://docs.oracle.com/cd/E17952_01/refman-5.5-en/char.html

Как сказал DCookie , char (1) более эффективен. Поскольку VARCHAR2 (VARCHAR) пуст, содержит 1 байт, но когда мы сохраняем 1 символ, тогда пустой размер 1 байта + с размером символа 1 байт -> 2 байта должен хранить 1 символ в varchar

Вот обсуждение Ask Tom по этой теме. Дает ориентированный на 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

Согласно этому руководству Oracle, вы должны использовать NUMBER (3). Сумасшедший, но правда.

http://docs.oracle.com/cd/B19306_01/gateways.102/b14270/apa.htm

Используйте CHAR (1) и ограничение, чтобы разрешить только «1» и «0».

...

col CHAR(1),
CONSTRAINT cons_atable_col1 CHECK (col1 IN ('1','0'))

Вопрос старый, но до тех пор, пока не будет использована последняя версия oracle, это все еще правильный вопрос.

Я бы решил проблему следующим образом: Создайте таблицу, которая содержит возможные значения для true / false плюс локализованный текст дисплея fe T $ KEYWORDS ITEMNO ITEMTEXT ITEMTEXT_DE ITEMTEXT_FE ... 0 False Falsch 1 True Wahr

Вместо True / False это может быть также выбрано, не выбрано и т. Д.

. Затем добавьте toeigh ключ к вашей колонке к этой таблице. Таким образом, у вас есть только допустимые значения, и они не меняются с локализацией.

Другое хорошее решение imho использует ограничение проверки в столбце данных. Этот параметр cc не работает, если ваши значения могут отличаться в одной и той же базе данных / столбце в зависимости от локализации клиентов.

alter table tblLocations add flag number CONSTRAINT <constraintname> CHECK (flag IN (1,0));

Oracle использует «биты» (а не тип данных per se) в разных представлениях словаря данных.

Например, представление dba_users имеет:

..
        , DECODE (BITAND (u.spare1, 128), 128, 'YES', 'NO')
..
        , DECODE (BITAND (u.spare1, 256), 256, 'Y', 'N')
..

, который показывает способ обхода этого в некотором роде. Если вам не нужно часто изменять «логические» биты, вы можете использовать тот же подход, что и Oracle с Oracle 6 (по крайней мере). Создайте таблицу с столбцом NUMBER и VIEW поверх того, что скрывает сложность операций BITAND.

ps. С другой стороны, Oracle JDBC имеет тип данных «бит» https://docs.oracle.com/cd/E16338_01/appdev.112/e13995/oracle/jdbc/OracleTypes.html#BIT as как вы уже знаете, PL / SQL имеет Boolean. Хотя это, вероятно, вам не поможет. См. Подход BITAND выше, если он соответствует вашему делу.

Число (1) не лучше, чем char (1). Особенно, если это будет в дополнение к существующему char (1). Это просто добавит к путанице.

FWIW, Oracle во внутренних представлениях (например, USER_TAB_COLUMNS) использует varchar2 (3) (YES и NO). Не уверен, что они здесь 100%.