Есть ли логический тип в базах данных Oracle?

Question

Есть ли логический тип в базах данных Oracle?

141

Существует ли логический тип в оракулных базах данных, аналогичный типу BIT в MS SQL?

Peder 16 сен. 2010, в 12:54

Источник

6

К сожалению, Oracle не полностью поддерживала стандарт ANSI SQL: 1999 ( en.wikipedia.org/wiki/SQL:1999 ), когда он был представлен.
Jeffrey Kemp 17 сен. 2010, в 04:36
2

Альтернативная точка зрения (почему SQL не должен иметь логический тип): vadimtropashko.wordpress.com/2010/09/16/…
Jeffrey Kemp 17 сен. 2010, в 04:48
5

@JeffreyKemp Этот блог бессмысленный. Тот факт, что некоторые логические значения могут быть вычислены на основе других полей в таблице, не означает, что все логические поля могут быть вычислены. Например, «is_trusted_customer», где это верно, если и только если человек решит: «Я доверяю этому человеку».
Jacob 22 янв. 2014, в 01:37
0

@Jacob (просто играю адвокат дьявола здесь) "is_trusted_customer" может быть изменен как "customer_trust_score> 0" :) PS Я не обязательно согласен со статьей.
Jeffrey Kemp 22 янв. 2014, в 04:28
0

возможный дубликат логического поля в Oracle
user565869 03 июль 2014, в 14:42
1

@JeffreyKemp Поздравляем, вы только что заново изобрели логические значения в стиле C (где вместо этого вы используете int s). Мы обязательно должны вернуться к тем, что в коде. Кроме того, аргумент полностью распадается, если типы данных между столбцами таблицы и столбцами результата (из SELECT ) являются общими, поскольку абсолютно логично возвращать логическое значение в качестве вычисленного результата, иногда даже с учетом остальной части аргумента.
jpmc26 21 апр. 2015, в 19:26
0

Нет, я ничего не изобрел. В выражении «оценка> 0» оценка - это число, а не логическое значение (стиль C или другое).
Jeffrey Kemp 26 апр. 2015, в 13:33
1

@JeffreyKemp Моя точка зрения заключается в том, что если приложения и пользователи не заботятся о величине оценки (это единственный раз, когда вы рассматриваете использование логического вместо числа), то это фактически является логическим, где все> 0 истина и 0 ложь. Такой выбор фактически скрыл бы истинное значение колонки без улучшения системы. (Я знаю, что вы не обязательно согласны с точкой зрения статьи, поэтому я прошу прощения, что моя формулировка была довольно личной. Я хотел рассмотреть эту концепцию.)
jpmc26 29 апр. 2015, в 17:12
2

Да. Больше типов данных, таких как булевы значения, дадут более точную выразительную силу - вы не получите от меня никаких аргументов в этом отношении. Я просто рад, что у нас, по крайней мере, есть тип DATE - представьте, что вам все время приходится иметь дело со строковыми представлениями дат :)
Jeffrey Kemp 29 апр. 2015, в 22:59
1

Чем больше типов данных, тем лучше. Наличие единственного числа в Oracle - это благословение. Говоря о датах, если бы даты были просто числами секунд (с некоторыми поддерживаемыми функциями), возможно, тогда нам не пришлось проходить глупый ритуал настройки множества часов два раза в год?
Tegiri Nenashi 07 июль 2015, в 23:50
0

@TegiriNenashi Oracle фактически поддерживает NUMBER, BINARY_FLOAT и BINARY_DOUBLE в SQL. Впрочем, последние два бесполезны.
David Aldridge 10 сен. 2015, в 07:48
1

Нет, логический тип данных не добавляет выразительной силы. Это просто синтаксический сахар для 0 и 1 значений. На самом деле, в отличие от логики, математики называют логические элементы элементами Z / (2). С практической точки зрения, как насчет логического соединения? Это простое умножение ху. Как насчет дизъюнкции? Это х + у-ху. Отрицание? 1-х.
Tegiri Nenashi 25 фев. 2016, в 19:09
0

@JeffreyKemp Если вы не саркастичны в отношении типа данных DATE : как использовать '01 -JAN-1970 'для создания даты или TO_DATE('2012-06-05', 'YYYY-MM-DD') не использует строки для представлять даты? Честно говоря, я бы предпочел просто хранить метки времени UNIX как значения NUMBER . (Это то, чему меня учили, и мне никогда не давали повода не делать этого.)
Agi Hammerthief 17 июль 2018, в 08:37
0

@AgiHammerthief нет, я не был саркастичным. Тип данных DATE - одна из лучших частей SQL. (Кстати, '01-JAN-1970' - это строка, а не дата; to_date возвращает date , а не строку). Значение DATE однозначно представляет дату (фактически, дату / время) (что-то, что строки и числа не могут сделать) и базовые операторы сравнения и арифметики работают с ним полезными способами, которые вы не можете сделать со строками или числовыми значениями.
Jeffrey Kemp 17 июль 2018, в 12:43
0

@JeffreyKemp В метках времени UNIX числа используются однозначно (количество секунд или миллисекунд до или после 01 января 1970 года, UTC / GMT или 0). '01-JAN-1970' и TO_DATE('2012-06-05', 'YYYY-MM-DD') оба используют строки для предоставления значений типу данных, который имеет некоторое другое (внутреннее) представление, которое не очевидно простым /визуальный осмотр. Любой приличный язык программирования (включая SQL) должен иметь функции String from_unix_timestamp(long inVal, String format) и long to_unix_timestamp(String inVal, String format) , часть которых должна позволять указывать формат даты, смещение TZ и DST.
Agi Hammerthief 17 июль 2018, в 13:46
0

@JeffreyKemp Для метки времени UNIX x в миллисекундах x + 1 вернется через 1 миллисекунду после x . x + (24 * 60 * 60 * 1000) вернется через 24 часа после x , при условии, что число миллисекунд в часе не увеличилось с даты, представленной x . В случае 1752 года метка времени UNIX на 01 January 1752 00:00:00 GMT+00:00 равна -6879427200000 . ДАТА Оракула будет представлять это как '01 -JAN-52 ', что является неоднозначным, учитывая отсутствие точности в части года и неспособность показать часы, минуты, секунды и смещение по Гринвичу.
Agi Hammerthief 18 июль 2018, в 12:05
0

@AgiHammerthief, нет - Oracle НЕ представляет даты в виде строк. '01-JAN-52' , как вы правильно '01-JAN-52' , это просто строка символов, не дата и, безусловно, неоднозначно. Oracle не использует подобные строки для представления дат.
Jeffrey Kemp 19 июль 2018, в 01:11

Показать ещё 15 комментариев

Теги:

database

sql

oracle

boolean

10 ответов

Ещё вопросы

К сожалению, Oracle не полностью поддерживала стандарт ANSI SQL: 1999 ( en.wikipedia.org/wiki/SQL:1999 ), когда он был представлен.
Альтернативная точка зрения (почему SQL не должен иметь логический тип): vadimtropashko.wordpress.com/2010/09/16/…
@JeffreyKemp Этот блог бессмысленный. Тот факт, что некоторые логические значения могут быть вычислены на основе других полей в таблице, не означает, что все логические поля могут быть вычислены. Например, «is_trusted_customer», где это верно, если и только если человек решит: «Я доверяю этому человеку».
@Jacob (просто играю адвокат дьявола здесь) "is_trusted_customer" может быть изменен как "customer_trust_score> 0" :) PS Я не обязательно согласен со статьей.
возможный дубликат логического поля в Oracle
@JeffreyKemp Поздравляем, вы только что заново изобрели логические значения в стиле C (где вместо этого вы используете int s). Мы обязательно должны вернуться к тем, что в коде. Кроме того, аргумент полностью распадается, если типы данных между столбцами таблицы и столбцами результата (из SELECT ) являются общими, поскольку абсолютно логично возвращать логическое значение в качестве вычисленного результата, иногда даже с учетом остальной части аргумента.
Нет, я ничего не изобрел. В выражении «оценка> 0» оценка - это число, а не логическое значение (стиль C или другое).
@JeffreyKemp Моя точка зрения заключается в том, что если приложения и пользователи не заботятся о величине оценки (это единственный раз, когда вы рассматриваете использование логического вместо числа), то это фактически является логическим, где все> 0 истина и 0 ложь. Такой выбор фактически скрыл бы истинное значение колонки без улучшения системы. (Я знаю, что вы не обязательно согласны с точкой зрения статьи, поэтому я прошу прощения, что моя формулировка была довольно личной. Я хотел рассмотреть эту концепцию.)
Да. Больше типов данных, таких как булевы значения, дадут более точную выразительную силу - вы не получите от меня никаких аргументов в этом отношении. Я просто рад, что у нас, по крайней мере, есть тип DATE - представьте, что вам все время приходится иметь дело со строковыми представлениями дат :)
Чем больше типов данных, тем лучше. Наличие единственного числа в Oracle - это благословение. Говоря о датах, если бы даты были просто числами секунд (с некоторыми поддерживаемыми функциями), возможно, тогда нам не пришлось проходить глупый ритуал настройки множества часов два раза в год?
@TegiriNenashi Oracle фактически поддерживает NUMBER, BINARY_FLOAT и BINARY_DOUBLE в SQL. Впрочем, последние два бесполезны.
Нет, логический тип данных не добавляет выразительной силы. Это просто синтаксический сахар для 0 и 1 значений. На самом деле, в отличие от логики, математики называют логические элементы элементами Z / (2). С практической точки зрения, как насчет логического соединения? Это простое умножение ху. Как насчет дизъюнкции? Это х + у-ху. Отрицание? 1-х.
@JeffreyKemp Если вы не саркастичны в отношении типа данных DATE : как использовать '01 -JAN-1970 'для создания даты или TO_DATE('2012-06-05', 'YYYY-MM-DD') не использует строки для представлять даты? Честно говоря, я бы предпочел просто хранить метки времени UNIX как значения NUMBER . (Это то, чему меня учили, и мне никогда не давали повода не делать этого.)
@AgiHammerthief нет, я не был саркастичным. Тип данных DATE - одна из лучших частей SQL. (Кстати, '01-JAN-1970' - это строка, а не дата; to_date возвращает date , а не строку). Значение DATE однозначно представляет дату (фактически, дату / время) (что-то, что строки и числа не могут сделать) и базовые операторы сравнения и арифметики работают с ним полезными способами, которые вы не можете сделать со строками или числовыми значениями.
@JeffreyKemp В метках времени UNIX числа используются однозначно (количество секунд или миллисекунд до или после 01 января 1970 года, UTC / GMT или 0). '01-JAN-1970' и TO_DATE('2012-06-05', 'YYYY-MM-DD') оба используют строки для предоставления значений типу данных, который имеет некоторое другое (внутреннее) представление, которое не очевидно простым /визуальный осмотр. Любой приличный язык программирования (включая SQL) должен иметь функции String from_unix_timestamp(long inVal, String format) и long to_unix_timestamp(String inVal, String format) , часть которых должна позволять указывать формат даты, смещение TZ и DST.
@JeffreyKemp Для метки времени UNIX x в миллисекундах x + 1 вернется через 1 миллисекунду после x . x + (24 * 60 * 60 * 1000) вернется через 24 часа после x , при условии, что число миллисекунд в часе не увеличилось с даты, представленной x . В случае 1752 года метка времени UNIX на 01 January 1752 00:00:00 GMT+00:00 равна -6879427200000 . ДАТА Оракула будет представлять это как '01 -JAN-52 ', что является неоднозначным, учитывая отсутствие точности в части года и неспособность показать часы, минуты, секунды и смещение по Гринвичу.
@AgiHammerthief, нет - Oracle НЕ представляет даты в виде строк. '01-JAN-52' , как вы правильно '01-JAN-52' , это просто строка символов, не дата и, безусловно, неоднозначно. Oracle не использует подобные строки для представления дат.

Erich Kitzmueller · Answer 1 · 2010-09-16T13-39-00.000Z

164

В Oracle SQL (не PL/SQL) отсутствует некий логический тип данных, но у них также нет четкой рекомендации относительно того, что использовать. См. этот поток на asktom. Из рекомендаций CHAR(1) 'Y'/'N' они переключаются на NUMBER(1) 0/1, когда кто-то указывает, что 'Y'/'N' зависит от английского языка, в то время как, например, Немецкие программисты могут вместо этого использовать 'J'/'N'.

Хуже всего то, что они защищают это глупое решение, как будто они защищают глупость ''=NULL.

Erich Kitzmueller 16 сен. 2010, в 13:39

7

1/0, если не двусмысленно, по крайней мере менее двусмысленно.
Adam Musch 16 сен. 2010, в 16:13
0

Я также предпочитаю 1/0, но, конечно, вы также найдете людей с фоном Visual Basic, которые вместо этого выберут -1/0. ИМО, есть только одно вменяемое решение этой проблемы: Oracle должен создать логический тип данных. Не может быть так сложно, когда почти у каждой другой СУБД есть такая.
Erich Kitzmueller 16 сен. 2010, в 18:13
11

Но '' = NULL является ложным! «ЕСТЬ НУЛЬ - это правда. :)
Jim Davis 16 сен. 2010, в 20:19
4

Майкл-О: Я видел это несколько раз. Для меня это 0/1 все время, но другие программисты предпочитают J / N. (Я живу в немецкоязычной стране)
Erich Kitzmueller 07 фев. 2012, в 08:48
1

Я видел, как франкоязычные программисты также используют O / N ... (O для OUI)
Pierre Henry 04 май 2015, в 12:51
2

В качестве забавы позвольте мне упомянуть, что мне когда-то приходилось хранить очень большое число логических значений (сотни) в строках таблицы, и успешно объединять их все в небольшое количество типов NUMBER, получая доступ и в некоторых случаях индексируя их индивидуально с помощью функций BITAND, встроенных в представление. Я не уверен, что я буду заботиться снова, но это довольно круто в то время. Одной из особенно полезных функций была возможность находить строки, которые эффективно соответствуют 100+ предикатам в этих логических значениях, с помощью одного предиката в форме: «MY_NUMBER = 45439794».
David Aldridge 10 сен. 2015, в 08:01
1

Я хотел бы видеть всплывающий (говорящий) язык, где « yes и « no начинаются с одной и той же буквы ... (быстрое прибегание к помощи не помогает найти его)
Irfy 23 сен. 2015, в 10:36
9

@Irfy Недавно я увидел, что используются N и F , потому что ON и OFF начинаются с одной и той же буквы ...
JimmyB 10 дек. 2015, в 16:15
0

@ HannoBinder Бриллиант, спасибо :-)
Irfy 11 дек. 2015, в 17:35
3

Использование чего-то отличного от «Y / N», потому что ваш родной язык не является английским, имеет такой же смысл, как отказ от использования «SELECT», «FROM», «WHERE» и т. Д. По той же причине.
ocramot 30 сен. 2016, в 12:29
2

@ocramot: Для многих немецкоязычных программистов (работающих в немецкоязычной стране над программным обеспечением для немецкоязычного клиента ...) использование «J» и «N» имеет смысл. Это то, что вы должны ожидать. Кстати, в мире SAP принято использовать «X» для true и «» для false.
Erich Kitzmueller 30 сен. 2016, в 12:54
0

@ammoQ Я знаю, что я должен ожидать этого, я живу в Италии, и я привык находить "S / N" в качестве опции; но я все еще нахожу это странным в контексте, где все другие слова на английском языке, особенно если он заменяет логическое значение.
ocramot 01 окт. 2016, в 06:52
5

Можно утверждать, что в качестве замены логического, «T» / «F» имеет еще больший смысл
Erich Kitzmueller 03 окт. 2016, в 08:32
1

это очень глупо при использовании ORM, как Entity Framework. Вы должны прыгать через обручи, чтобы карта выше безумия.
Sonic Soul 18 апр. 2017, в 14:49
2

В ответе есть одна небольшая ошибка ''=NULL не соответствует действительности, но '' IS NULL . )))
GingerHead 05 июль 2017, в 09:52
0

@GingerHead Спасибо за ваш комментарий. = Не подразумевается буквально как SQL-оператор, но логически - как в Oracle трактует NULL и '' то же самое
Erich Kitzmueller 05 июль 2017, в 09:55
4

Да, я знаю, что именно вы имели в виду, но я хотел саркастически выделить любопытные понятия об Oracle.
GingerHead 05 июль 2017, в 09:59

Показать ещё 15 комментариев

Bohdan · Answer 2 · 2014-06-24T22-10-00.000Z

26

Неа.

Может использовать:

IS_COOL NUMBER(1,0)

1 - true
0 - false

--- наслаждайтесь Oracle

Или используйте char Y/N как описано здесь

Bohdan 24 июнь 2014, в 22:10

4

Я предпочитаю char (1), потому что он занимает меньше места. Вы можете проверить это следующим образом: create table testbool (boolc char(1), booln number(1)); insert into testbool values ('Y', 1 ); select dump(boolc), dump(booln) from testbool; Этот CHAR хранится: Typ=96 Len=1: 89 и что NUMBER: Typ=2 Len=2: 193,2 По крайней мере, в 12c NUMBER (1) может использовать 2 байта ...
phil_w 19 апр. 2016, в 17:29

Alex Stephens · Answer 3 · 2015-09-10T07-28-00.000Z

23

В соответствии с ответами Ammoq и kupa, мы используем число (1) со значением по умолчанию 0 и не допускаем null.

здесь добавьте столбец для демонстрации:

ALTER TABLE YourSchema.YourTable ADD (ColumnName NUMBER(1) DEFAULT 0 NOT NULL);

Надеюсь, это поможет кому-то.

Alex Stephens 10 сен. 2015, в 07:28

14

Обратите внимание, что вы можете хранить -1 там же. Вы можете добавить проверочное ограничение, чтобы ограничить значения 0 и 1.
David Aldridge 10 сен. 2015, в 07:54
0

@DavidAldridge В логической логике любое число, отличное от 0 (FALSE), равно 1 (TRUE), поэтому не имеет значения, какое число хранится, что устраняет необходимость в проверочном ограничении. Добавление функции, которая возвращает логическое значение из int, тривиально: boolean intToBool(int in) { return (in != 0); }
Agi Hammerthief 17 июль 2018, в 13:59
2

@AgiHammerthief Верно, но если вы хотите найти строки, используя предикат для «логического» столбца, я бы лучше знал, что мои варианты: ColumnName = 0 или ColumnName = 1 , а не ColumnName = 0 или ColumnName <> 0 . Семантика последнего не дружит с программистом. Я также хотел бы сделать его более простым для оптимизатора запросов, имея два значения.
David Aldridge 17 июль 2018, в 21:30

Показать ещё 1 комментарий

vc 74 · Answer 4 · 2010-09-16T14-18-00.000Z

Не на уровне SQL и жаль В PLSQL есть один, хотя

kupa · Answer 5 · 2010-09-16T14-34-00.000Z

Нет такого типа boolean, но вместо этого вы можете использовать 1/0 (номер типа) или 'Y'/'N' (тип char), или 'true'/'false' (тип varchar2).

Pranay Rana · Answer 6 · 2010-09-16T13-03-00.000Z

4

Общим трюком для экономии пространства является сохранение значений boolean как Oracle CHAR, а не NUMBER:

Pranay Rana 16 сен. 2010, в 13:03

4

CHAR (1) и VARCHAR2 (1) идентичны в использовании пространства.
Tony Andrews 16 сен. 2010, в 13:13
3

Как я узнал здесь, docs.oracle.com/cd/E17952_01/refman-5.5-en/char.html когда мы рассказываем один символ, существует различие только между char и varchar - char использует 1 байт, но varchar использует 1 байт для пустого пространства + 1 байт для одного символа -> varchar (varchar2) использует 2 байта для 1 символа <, когда char использует только 1 байт
Artem.Borysov 23 июль 2015, в 17:04

Klaus Byskov Pedersen · Answer 7 · 2010-09-16T12-58-00.000Z

Существует тип boolean для использования в pl/sql, но ни один из них не может использоваться в качестве типа данных столбца.

Filburt · Answer 8 · 2010-09-16T15-06-00.000Z

3

Просто потому, что никто не упомянул об этом: использование RAW (1) также кажется обычной практикой.

Filburt 16 сен. 2010, в 15:06

0

Функция raw (1) хороша тем, что пользователь не может предположить, что в ней, человек, выполняющий запрос, должен понять, что находится в столбце raw (1), и перевести его во что-то осмысленное.
Jacob 22 янв. 2014, в 01:39
11

<sarcasm> Да, это так здорово, что вы не можете написать переносимый код JDBC с ним. </ sarcasm>
chubbsondubs 31 авг. 2014, в 16:12

Roberto Góes · Answer 9 · 2017-06-16T12-53-00.000Z

Нет, в базе данных Oracle нет булева типа, но вы можете сделать так:

Вы можете поместить ограничение проверки на столбец.

Если в таблице нет столбца проверки, вы можете добавить его:

ALTER TABLE table_name
ADD column_name_check char(1) DEFAULT '1';

Когда вы добавляете регистр, по умолчанию этот столбец получает 1.

Здесь вы помещаете чек, который ограничивает значение столбца, просто установите только 1 или 0

ALTER TABLE table_name ADD
CONSTRAINT name_constraint 
column_name_check (ONOFF in ( '1', '0' ));

zloctb · Answer 10 · 2015-08-07T05-44-00.000Z

DECLARE
error_flag  BOOLEAN := false;
BEGIN

error_flag := true;
--error_flag := 13;--expression is of wrong type

  IF error_flag THEN 

UPDATE table_a SET id= 8 WHERE id = 1;

END IF;
END;

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