Комментарии 67
Для True определен оператор сложения?
В общем случае да. Булева алгебра — логическое сложение. Только при трактовке «это Int» будут интересные спецэффекты :)
> The data type boolean comprises the distinct truth values True and False. Unless prohibited by a NOT NULL constraint, the boolean data type also supports the truth value Unknown as the null value.
Ну и так далее.
Так char(1) с constraint это тоже самое, какой смысл добавлять этот тип, который будет по сути синтаксическим сахаром (bool никто не пакует)
Другое похожее удобство — тип serial (в postgres), по сути автоматическое создание sequence для инкрементных полей, но это тоже очень приятная возможность (при этом делать руками sequence также никто не запрещает)
Отдельный тип это однозначная запись
Не все так просто в мире реляционных баз. Например, очень часто используются агрегирующие операторы, так что делать с этим типом, если мне нужно подсчитать сумму всех строк с включенным флагом (причем с группировкой)? sum(BooleanField) — логическое сложение даст нам совершенно не нужный результат, а с вариантом sum(cast(BooleanField as int)) — совсем некрасиво получается.
sum(case when fair then 1 else 0 end) as fair
Вообще, сумма по булевому полю это странный по смыслу кейс
А как вы будете считать сумму по char?
Использовать char — это оверхед для булевого значения, но мы обсуждаем первоначальную ветку
это частный случай целого.
Например, в MSSQL есть тип bit — его с головой хватает для репрезентации буля.
Вообще, сумма по булевому полю это странный по смыслу кейс
ну почему, вот есть таблица содержится список товаров: наименование, категория и с булевый признак наличия повреждений.
Вот я хочу сделать отчет который покажет распределение повреждений по группам товаров. Вот тут как раз сумма по полю признака наличия (если это будет 0/1) и поможет нам.
Использовать char — это оверхед
Чем оверхед? Занимает столько же, сколько и 0/1. Я не поклонник такого решения, но видел это крайне часто.
Например, в MSSQL есть тип bit
Мы вроде про Оракл.
сделать отчет который покажет распределение повреждений по группам товаров
По логике это count, который просто реализован через сумму. Для boolean можно либо использовать case (в комменте выше) либо написать красивую функцию c логичным названием countBool
Чем оверхед
Здесь я «синтаксическом оверхеде», т.е. так же как и с boolean мне придется делать приведение типа в агрегирующем операторе sum(case BooleanAsCharField when '1' THEN 1 и т.д.)
Поэтому char я не использую в булевых колонках и считаю это антипаттерном в отличии от tinyint
Мы вроде про Оракл.
Да, Oracle советует для Bit использовать Number(3), я вот даже не знаю почему.
По логике это count, который просто реализован через сумму.
Да, но в этом случае или мы используем материализацию вычисляемых данных или денормализацию, что не всегда лучшее решение.
Так суммируются-то не булевы поля
Сумма уже идет на агрегированные данные. В моем случае это категория товаров. Если все перенести в предикат (boolField = True), то тут выход создавать или CTE или подзапросы.
вот есть таблица содержится список товаров: наименование, категория и с булевый признак наличия повреждений.
Вот я хочу сделать отчет который покажет распределение повреждений по группам товаров.
Если я правильно понял постановку задачи,
-- тестил на rextester.com, с планшета
DROP TABLE t; -- там почему-то уже была
CREATE TABLE t (cat INT, name VARCHAR(32), damaged BOOLEAN);
INSERT INTO t VALUES
(1, 'armchair', False),
(1, 'desk', False),
(1, 'case', True),
(1, 'zappa', True),
(2, 'fan', True),
(2, 'pc', False),
(2, 'lamp', True),
(2, 'abacus', False),
(2, 'calculator', True),
(3, 'metal sphere 1 (absent)', False),
(3, 'metal sphere 2', True);
SELECT cat, COUNT(*) FROM t WHERE damaged = True GROUP BY cat ORDER BY cat;
# cat count
1 | 1 | 2
2 | 2 | 3
3 | 3 | 1
распределение повреждений по группам товаров.
отсутствие повреждений в категории это то же важно.
не включаютАй, действительно.
(1, 'case', False),
(1, 'zappa', False),
-- ...
SELECT cat, COUNT(NULLIF(damaged, False)) FROM t GROUP BY cat ORDER BY cat;
# cat count
1 | 1 | 0
2 | 2 | 3
3 | 3 | 1
Что, в общем-то, аналог решений с case. Мне кажется, это больше вороос выбора между семантикой («логический атрибут должен быть boolean») и удобством использования (просуммировать tinyint).
семантикой («логический атрибут должен быть boolean») и удобством использования (просуммировать tinyint).
Поэтому мне нравится как сделано в MS SQL Server — там есть тип bit может быть 0 или 1. плюс в предикатах поддерживают неявные 'TRUE' и 'FALSE'
А чем "PL/SQL" у Oracle отличается от "Определяемые пользователем функции" у PostgreSQL?
Oracle вводит запрет на предоставление, экспорт или реэкспорт товаров, услуг и технологий, поддерживающих проекты, которых касаются санкции США
С Java точно такое же положение?
Если вас действительно интересует Тиберо
Я бы выбрал PostgreSQL, а в статье не увидел ни одного довода, что бы заинтересоваться, в том числе и политического. Возможно, кому-то будет интресно, что она платная и можно будет организовать откаты, но думаю что в PostgreSQL бабло можно будет тоже попилить на поддержке, если уж брать гос. сектор, но, по крайней мере хотя бы IT спецам копеечка перепадёт, а не менеджерам иностранного представительства. Не стоит отвечать, это мысли в слух.
Как только США заблокирую долларовые счёта компании(а они оставляют себе право это делать в отношении компаний и банков которые нарушают их санкции) никто и не вспомнит про то что там были какие-то отношения.
Наоборот исчезают проблемы лицензирования.
Объявить ихнее ПО — «трофейным» и юзать дальше…
P.S. А то в нашей конторе столько бабок уходит на лицензии Oracle, SAP, MS, Vmware…
Была специально для вас какая-то СУБД по типу БолгенОС.
Я например не понимаю почему его еще нет на флаге.
А проблема скорее всего будет решаться именно таким образом. Только будет какая-то местная депутатская контора, которая будет шильдик менять и продавать готовое решение. Большинство вендоров будут закрывать на это глаза, пока пираты будут оставаться на санкционной территории: рынок для них все рано закрыт, а так он останется недоступным для потенциальных конкурентов, и наст надежда на быстрое возвращение позиций в обозримом будущем.
По заявлениям, Тиберо позволяет прозрачно перейти с Оракла. Переход на Постгрес — это переписывание 80% серверной части.
А цифра — чисто умозрительно из своего опыта перехода на Постргес. Хоть постгресовцы и лепили свой pgpl/sql глядя на pl/sql, но отличаются они сильно, в том числе по идеологии.
А еще если использовался апекс — то ему замены вообще нет и, соответственно, полное переписывание интерфейса на абсолютно новой платформе.
Тут статья про крупные компании попавшие под санкции, не думаю что в ключевых местах они могут себе позволить использовать что-то похожее на hibernate
Наверное от способа подсчёта зависит, для России, к примеру, первые несколько банков это сколько? Вроде в штуках не много а в процентах от объёма бизнеса/сумм затраченных на лицензии и поддержку.
Avito, обрабатывая до 6000 транзакций в секунду, а «Яндекс» применяет PostgreSQL в одном из своих сервисов, обрабатывая более 500 млн. транзакций в сутки.
Красиво написано, но бессмысленно — писал маркетолух. Нужно приводить к одной единице измерения. Если это сделать, то будет проще — авито < 6000/с, яндекс > 6000/с.
Нефтегазовая дилемма: в поиске альтернативных СУБД