Комментарии 67
Понимаю, что Oracle мощный продукт и все такое, но мне как разработчику не жалко потерять СУБД, которая в 2018 году не дает создать булеву колонку, заставляя разработчика выдумывать фигню типа 'Y'/'N' или 0/1.
«булевская колонка», как ты её назвал, это частный случай целого.
символ тоже частный случай целого
Откуда такое определение? Для True определен оператор сложения?
SQL стандарт с вами не согласен:
> 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.
Ну и так далее.
> 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.
Ну и так далее.
Думал, это только MSSQL подобным страдало (до относительно недавнего времени).
Так char(1) с constraint это тоже самое, какой смысл добавлять этот тип, который будет по сути синтаксическим сахаром (bool никто не пакует)
Из таких мелочей и складывается удобство. Отдельный тип это однозначная запись (а не варианты либо с char(1) либо с tinyint) и понятные простые логические операторы. Плюс, если используется ORM, не надо городить конвертер для перевода в boolean в объекте.
Другое похожее удобство — тип serial (в postgres), по сути автоматическое создание sequence для инкрементных полей, но это тоже очень приятная возможность (при этом делать руками sequence также никто не запрещает)
Другое похожее удобство — тип serial (в postgres), по сути автоматическое создание sequence для инкрементных полей, но это тоже очень приятная возможность (при этом делать руками sequence также никто не запрещает)
Отдельный тип это однозначная запись
Не все так просто в мире реляционных баз. Например, очень часто используются агрегирующие операторы, так что делать с этим типом, если мне нужно подсчитать сумму всех строк с включенным флагом (причем с группировкой)? sum(BooleanField) — логическое сложение даст нам совершенно не нужный результат, а с вариантом sum(cast(BooleanField as int)) — совсем некрасиво получается.
А как вы будете считать сумму по char? Но вообще есть, например, вот такой вариант:
sum(case when fair then 1 else 0 end) as fair
Вообще, сумма по булевому полю это странный по смыслу кейс
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, который просто реализован через сумму.
Да, но в этом случае или мы используем материализацию вычисляемых данных или денормализацию, что не всегда лучшее решение.
Так суммируются-то не булевы поля, а поля в записях, где булево поле имеет определённое значение. Типа, SELECT sum(intField) FROM t WHERE boolField = True. Либо count(*) WHERE, если число записей.
Так суммируются-то не булевы поля
Сумма уже идет на агрегированные данные. В моем случае это категория товаров. Если все перенести в предикат (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).
А чем "PL/SQL" у Oracle отличается от "Определяемые пользователем функции" у PostgreSQL?
Oracle вводит запрет на предоставление, экспорт или реэкспорт товаров, услуг и технологий, поддерживающих проекты, которых касаются санкции США
С Java точно такое же положение?
Такая классная СУБД, а нет сертификации VMWare?
НЛО прилетело и опубликовало эту надпись здесь
Tibero — не Китай. Южная Корея.
То есть, полностью лежит под США и не смеет пикнуть против, в отличии от КНР?
Если вас действительно интересует Тиберо как альтернатива, то вместо троллинга поинтересуйтесь последними тенденциями в отношениях США и ЮКореи и России и ЮКореи. Узнаете много нового.
Если вас действительно интересует Тиберо
Я бы выбрал PostgreSQL, а в статье не увидел ни одного довода, что бы заинтересоваться, в том числе и политического. Возможно, кому-то будет интресно, что она платная и можно будет организовать откаты, но думаю что в PostgreSQL бабло можно будет тоже попилить на поддержке, если уж брать гос. сектор, но, по крайней мере хотя бы IT спецам копеечка перепадёт, а не менеджерам иностранного представительства. Не стоит отвечать, это мысли в слух.
Простите что отвечаю, но вот есть возможность и ИТ спецам «копеечку» получить — tmaxsoft.su/news/promo-usd-1
НЛО прилетело и опубликовало эту надпись здесь
Как только США заблокирую долларовые счёта компании(а они оставляют себе право это делать в отношении компаний и банков которые нарушают их санкции) никто и не вспомнит про то что там были какие-то отношения.
НЛО прилетело и опубликовало эту надпись здесь
Не понимаю проблемы санкций.
Наоборот исчезают проблемы лицензирования.
Объявить ихнее ПО — «трофейным» и юзать дальше…
P.S. А то в нашей конторе столько бабок уходит на лицензии Oracle, SAP, MS, Vmware…
Наоборот исчезают проблемы лицензирования.
Объявить ихнее ПО — «трофейным» и юзать дальше…
P.S. А то в нашей конторе столько бабок уходит на лицензии Oracle, SAP, MS, Vmware…
А когда надо будет обновить ПО из-за дыр или недостающих функций, то производитель (даже если не связан с санкциями) подумает «а надо ли оно ему».
Была специально для вас какая-то СУБД по типу БолгенОС.
Была специально для вас какая-то СУБД по типу БолгенОС.
и весёлого роджера на государственный флаг. Ну удачи вам дженельмены…
Я например не понимаю почему его еще нет на флаге.
А проблема скорее всего будет решаться именно таким образом. Только будет какая-то местная депутатская контора, которая будет шильдик менять и продавать готовое решение. Большинство вендоров будут закрывать на это глаза, пока пираты будут оставаться на санкционной территории: рынок для них все рано закрыт, а так он останется недоступным для потенциальных конкурентов, и наст надежда на быстрое возвращение позиций в обозримом будущем.
НЛО прилетело и опубликовало эту надпись здесь
> почему нужно выбирать платную Tibero
По заявлениям, Тиберо позволяет прозрачно перейти с Оракла. Переход на Постгрес — это переписывание 80% серверной части.
По заявлениям, Тиберо позволяет прозрачно перейти с Оракла. Переход на Постгрес — это переписывание 80% серверной части.
Откуда такая цифра? Почему не 70 или не 90%? Все оочень сильно зависит от проекта
Конечно все зависит от проекта.
А цифра — чисто умозрительно из своего опыта перехода на Постргес. Хоть постгресовцы и лепили свой pgpl/sql глядя на pl/sql, но отличаются они сильно, в том числе по идеологии.
А еще если использовался апекс — то ему замены вообще нет и, соответственно, полное переписывание интерфейса на абсолютно новой платформе.
А цифра — чисто умозрительно из своего опыта перехода на Постргес. Хоть постгресовцы и лепили свой pgpl/sql глядя на pl/sql, но отличаются они сильно, в том числе по идеологии.
А еще если использовался апекс — то ему замены вообще нет и, соответственно, полное переписывание интерфейса на абсолютно новой платформе.
Я к тому, что не всегда используется чистый sql, куда чаще в энтерпрайзе всякие ORM типа hibernate. При таком подходе, если нет использования нативных оракловых функций, переезд будет не такой болезненный
Я-ж специально написал: 80% серверной части.
Тут статья про крупные компании попавшие под санкции, не думаю что в ключевых местах они могут себе позволить использовать что-то похожее на hibernate
Один из ключевых параметров для СУБД не рассмотрен — уровни изоляции транзакций. Что там предлагает Tibero?
Имею опыт пользования одним корейским продуктом (относится к онлайн играм), и исходя из своих наблюдений, у корейцев довольно специфические методы в разработке, поддержке. Не скажу, что они пишут софт лучше или хуже остальных, но свои нюансы довольно заметны. Например, могут развивать одну фичу пару лет, потом когда всё отладится и заработает, развернут направление на 180 градусов. Хромает последовательное развитие, много бесполезных экспериментов. А в отношении, где крутятся крупные корпоративные пользователи, такие штуки не приветствуются.
НЛО прилетело и опубликовало эту надпись здесь
Ничего подозрительного. В TmaxSoft прайс-лист открыт для партнеров. А любое предложение для заказчика действительно индивидуально, если это не заказчик SMB, это везде так. Да и для рынка SMB в TmaxSoft действует сейчас хорошее предложение для разработчиков: лицензия за 60 руб, годовая техподдержка за 99 тыс руб.
Откуда такая доля Oracle? Почему не установленный везде, как мне кажется, MS SQL Server?
Наверное от способа подсчёта зависит, для России, к примеру, первые несколько банков это сколько? Вроде в штуках не много а в процентах от объёма бизнеса/сумм затраченных на лицензии и поддержку.
На самом деле доля Oracle еще больше, чем 46%. Я согласен с 70%. Знаю не понаслышке: 8 лет в Oracle. Это серое использование, когда у заказчика официально лицензируется только верхушка айсберга. Кроме того, некоторые просто скачивают дистрибутив и пользуются СУБД. Поэтому, потенциал Tibero огромный.
Avito, обрабатывая до 6000 транзакций в секунду, а «Яндекс» применяет PostgreSQL в одном из своих сервисов, обрабатывая более 500 млн. транзакций в сутки.
Красиво написано, но бессмысленно — писал маркетолух. Нужно приводить к одной единице измерения. Если это сделать, то будет проще — авито < 6000/с, яндекс > 6000/с.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нефтегазовая дилемма: в поиске альтернативных СУБД