Я и не спорю. Сначала бизнес-задача, ТЗ. Так и стаття о том как проектировать програму, а не решать бизнес задачу. Ето уже подразумевает наличие ТЗ в том или ином виде.
Если заведомо не известно, что задача потребует очень больших скоростей записи и чтения данных, их поиска и агрегации, с которыми без БД не справиться за разумное время, и то каждый байт в схеме должен быть максимально оптимизирован, то начинать проектировать с БД очень похоже на попытку преждевременной оптимизации.
Вот так и рождаются програмы с которими работать не возможно. Я обясню что я имею ввиду, говоря правильная програма: Откритие журналов -до 3 с, отркритие документа до 2 с, Отчети до 5с (в некоторих очень редких случаях до 40с иначе регулярние отчеты и OLAP). И неважно что у вас несколько лет в БД, в таблицах милиарды строк и размер в терабайтах.
Приступая к разработке задачи ви должни четко понимать какой обем может быть через год и через 5 лет с учотом роста компании. И здесь нет преждевременной оптимизации, Разници в скорости проектирования модели в БД или JAVA\C#\… нет в принципе. Ибо нужно проектировать структуру учитивая возможние изменения ТЗ, и разширение БЛ.
И как уже говорилось — сгенерировать клас на основании обекта БД проще-простого.
Здесь беда в другом сейчас слишком много разработчиков и груп разработчиков, которие вообще не хотят заморачиватся елементарними знаниями БД. И считают что програма должна бить БД независимая. И ето чуть ли не ее главная фича.
P.S. И да, я старовер. Я не люблю ORM, ибо не представляю что под капотом, и что он сгенерит, и я считаю что реализация бизнес логики на БД наиболее правильное место(самое ефективное). Приетом скорость разработки и скорость работи више.
Вот вам аргументи
1) Поддерка целосности на БД делается елементарно.
2) БД неплохо так паралелит задачи.
3) БД (Оракл) имет так званий result cache для запросов и функций, которий отслеживает изменения таблиц и всегда видает достоверний результат. При етом доступно всем пользователям. Я даже не представляю сколько нужно потратисть усилий чтоб достичь такого результата самостоятельно.
4) Ну и в Pl/sql есть возможнось компиляции в нативний код.
Из минусов только GUI для C#/JAVA покруче и тесты писать сложнее. Отладка кода на БД ничем не хуже/сложнее чем в VS.
Я полностю согласен с автором статти. Я само хотел написать что-то похожее, но изложение мислей не мой конек. Возможно когда ви проектируете игру — база даних и не стоит на первом месте. Но даже в етом случае если начать проектировать с БД можнополучить профит. Но если ви проектируете програму для бизнеса — итог ее работи практически всегда должен бить: коректние, согласование дание в БД.
Да я знаю про весь етот зоопарк. Но ведь чтоб PL/… вызвать SQL или же наоборот в запросе обратится к процедуре на PL/… теряется очеть много ресурсов. И все ето очень не нативно(как то сбоку к БД). В оракле етому (скорости переключение контекста) уделяется огромное внимание. В плоть до того что сделали хинт процедурам указивающий что процедура специально создана для SQL. Кроме того возможможность компелировать в нативний код. + Разбор SQL делается на момент компиляции и тд. Ведь основноя задача встоеного язика работать з базой. А здесь все намного полутше в оракла.
Да 100% писать код на C# или JAVA намного удобнее чем на PL/SQL за счет GUI синтаксиса и тд. Но когда задача работать с транзакциями и даними Pl/sql действительно хорош.
Если поработать на Oracle несколько лет то все его богатство (SQL, PL\SQL, Администрирование ) становится нормой. И когда возвращаешся на что то другое, ето как пересесть с мерседеса на ладу калину :)
У каждой БД есть свои слабые и сильние стороны. И я считаю что PG лутшая из безплатных. Оракл — просто лутшая.
Если по сравнению pl/sql реально на порядок круче pgsql по возможностям, лаконичности, ориентации на быстодействие, и тд.
Из возможности БД — партиции явно еще не продакшин да и базових возможностей партиций на порядок меньше, такие фичи как кеш резалт — просто волшебная палочка.
Да и отсуствие merge. Оптимизатор намного круче и тд. Ето то что что пришло на ум за несколько минут. Да и скаждой новой версией Оракл не перестает удивлять.
Тут писали что t-sql крутой, для меня он реально топорний. Я с трудом представляю что кто то решится писать всю бизнес логику на t-sql или на pgsql. C ораклом на такое решится без проблем. Там управляемость и скорость, которою очень сложно достичь на высокоуровневых языках.
P.S. Неохота разводить холивар БЛ БД VS С\С+\C#\JAVA\…
Распараллеливание — хорошая вещь только для DW баз где запросов меньше ядер. Для OLTP задач где как правило одновременних запросов больше чем ядер общая производительность может деградировать. Паралелизм может дать общее ускорение только на небольшом количестве задач.
Тригер на уровне операторов вообще зачетная вещь как и многоколоночная статистика.
Ну и партиции.
В целом PostgreSQL движется в правильном направлении.
Вот так взяли и забыли про Siemens. :)
Круче поддержки небыло ни в какой другого производителя.
Досих пор живой E71 и EL71.
Там и мультизадачность и мультисим, аська и софта написано… И размер что надо.
Все кнопки настраивались.
У меня смартфон бил вторым телефоном годика так 3.
Очень спорное утверждение. Если вы правильно используете БД значит вы используете тригера, процедуры, пакеты, функции, особенности БД в запросах и вюхах а ето от несколько десятков тисяч до нескольких сотен тисяч строк.
Разница в запросах + их оптимизация, не говоря уже о разнице pl/sql t-sql и pg/sql настолько огромная что ето фактически наново писать всю логику. То есть ето в принципе невозможно. А переход с версионника на блокировщик или наоборот ето еще то приключение, вплоть то переписивания логики приложения.
А то о чем вы говорите — ето способ писать приложения только используя SQL, а всю логику вне БД. При етом вы используете только незначительную часть возможности БД.
P.S. Была попотка перенести приложение c оракла на IBM DB2 которий декларировал совместимость pl/sql на 99%. Так от все вкусняшки по быстродействию оракла в pl/sql DB2 там не реализованы. Хотя я уверен есть свои. Оценив неоходимое время — мы отказались.
Как мне надоело ето восхваление постгрес. Где би что не обсуждалось по БД там уже расказивают какой постгрес крутой и сколько даст прироста. Да ето очень крутая БД. Точно лутшая с безплатных версионников. :)
А по факту:
1) В класе версионник он отстал от оракла навсегда.
2) Партиции которие дают реальний прирост и маштабируемость появилось буквально в 10 версии и назвать что ето уже продакшин — как-то язик не поварачивается. Про in-memory в посгри я тоже ничего не слишал. (Оракл 12, MSSQL 2014). Пускай реализация местами странная и ограничений вагон и тележка но оно работает и дает реальний прирост.
Если правильно настроить базу и експлуатировать ее как она «любит» то на одном и том же железе разница может бить в процентах а не в разы.
Раз стаття називается «Рассуждение на тему, какую базу данных выбирать» а не
«Рассуждение на тему, какую безплатную базу данных выбирать»
Если у вас есть деньги посмею дополнить: MSSQL — мощная, легкая в администрировании. ORACLE — наверное самая лутшая SQL БД з самим быстрим и мощным встроеним язиком PL/SQL (для любителей писать логику на БД)
Из недочотов — цена. Сложность администрирования.(с каждой новой реализацией становится проще)
Обе имеют Inmemory опции(очень разние по сути реализации).
Обе есть смисл покупать только в enterprise варианте, ибо вкусние плюшки только в enterprise редакции.
Такие результаты можно получить только когда ноды не конкурируют за блоки. Чем больше нод тем большая конкуренция. В OLTP системах с етим беда. Я понимаю что ERP ето больше OLTP система — но она очень модульная. Если вручную разносить задачи по нодам в принцепе возможно наверное. Но и главное RAC ето уже екзотика.
Во времена когда RAC был актуален специалисты оракл озвучивали цифры
ноди Производительность относительно одной ноди
2 — 160%-180%
3 — 200%-240%
4- 240%-260%
При большем количестве смисл вообще терялся.
Поетому одна машина на power действительно лучше 2 нодовой x86 конфигурации.
Как говорят есть правда ложь и статистика тесты. По каждому из тестов power показал в 3-4 кратное превосходство. + вопрос в качестве паралелизма в етих тестах. Ну и главное какое отношение ети тести имеют к производительности БД? Я писал что платфома имеет значение а не только сами ядра проца.
Для примера. У нас был RAC с друх 2 сокетних x86 в каждом 4 реальних ядра (8- гипертрейдинг) 2*2*4 =16 ядер.
После перехода на 8 ядер power (Пез измений ПО, хранилища и версии БД) система стала на много отзивчивее. (без дополнительного тюнинга) После тюнинга прекрасно себя чувствовала на 4 ядрах. Я понимаю что прошло время и сейчас 20 ядер в сокете и тд… но не думаю что соотношение ядер сильно поменялось.
Вопрос в производительности БД на ядро, которое лицинзируется. Да и никто не сомневается что exadata, которая проектировалась под Оракл и будет имень очень хорошую производительность. К сожелению с exadata не работал. То если условно нужна производительность X то POWER + Лицензии oracle будет дешевле чем exadata + Лицензии oracle
Есть практический опит работи с oracle на power и x86. так вот оракл уж слишком сильно пепреценил ядро x86 :) его реальний коефициет -0.2-0.3 к POWER и вопрос не в самом процесоре/ядре а в платформе в целом.
1) Автор просто молодец. От него ожилали рутинную работу — он занялся автоматизацией и на минуточку ускорил процес в 20!!! раз. Кроме того после етого етапа зделать полную автоматизацию будет намного проще.
2) Но я всегда говорю что EXCEL ето програма которая наносит наибольший вред компаниям. Она отодвигает необходимую автоматизацию предприятий.
3) Ну и зделаю неблагодарную вещь, дам совет — Бегите с етого предприятия.
а) они в 2018 работали с бумажками.
б) они не поощрили увеличение производительности труда.
На таком предприятии работать безперспективно.
Тема образования для меня достаточно больная. Я еще застал так званое «советское» образование (прикладная математика специализация С\С++). І учась на 2 курсе я ясно осознавал бесполезность и несуразность классического образования. Уж извините меня но 2 часа лекций и один час практики практически по всем математическим дисциплинам — бред. Никакой ценности такое образование не имело. Все что я вынес с университета — возможнось общения с умными сверсниками и преподавателями (инета еще у нас не было). Вы реально считаете что програмистам нужно соотношение сухой мат теории и програмирования 2:1 или еще хуже 3:1. И не надо говорить что обучение вышей математики развивает и тд. Ето не правда. на третьем курсе, когда у был спецкурс по олимпиадам я осознал что решаю задачи хуже чем до вступления!!! Одним словом обучение ну очень помогло :) И да все пары которые можно было прогулять я сидел в аспиранской и писал курсовые и дипломные.
Но самое ужасное в том, что когда моя дочь поступила на один из лучшых тех вуз страны (Украина) Я узнал что в вузах практически ничего не поменялось. все тоже безобразное соотношение предметов математики и програмирования и теории к практике. Все те же глупые акценты и система оценивания. Причем среднее образование ничем не лучше. Но ето уже другая тема. :)
Ну да 0.5M строк кода на PL/SQL — не показатель :)
наибольшая табличка > 550 000 000 строк ежедевно увеличиваєтся 300 000 строк и ето не логи а таблица влияющая на остатки.
Вот так и рождаются програмы с которими работать не возможно. Я обясню что я имею ввиду, говоря правильная програма: Откритие журналов -до 3 с, отркритие документа до 2 с, Отчети до 5с (в некоторих очень редких случаях до 40с иначе регулярние отчеты и OLAP). И неважно что у вас несколько лет в БД, в таблицах милиарды строк и размер в терабайтах.
Приступая к разработке задачи ви должни четко понимать какой обем может быть через год и через 5 лет с учотом роста компании. И здесь нет преждевременной оптимизации, Разници в скорости проектирования модели в БД или JAVA\C#\… нет в принципе. Ибо нужно проектировать структуру учитивая возможние изменения ТЗ, и разширение БЛ.
И как уже говорилось — сгенерировать клас на основании обекта БД проще-простого.
Здесь беда в другом сейчас слишком много разработчиков и груп разработчиков, которие вообще не хотят заморачиватся елементарними знаниями БД. И считают что програма должна бить БД независимая. И ето чуть ли не ее главная фича.
P.S. И да, я старовер. Я не люблю ORM, ибо не представляю что под капотом, и что он сгенерит, и я считаю что реализация бизнес логики на БД наиболее правильное место(самое ефективное). Приетом скорость разработки и скорость работи више.
Вот вам аргументи
1) Поддерка целосности на БД делается елементарно.
2) БД неплохо так паралелит задачи.
3) БД (Оракл) имет так званий result cache для запросов и функций, которий отслеживает изменения таблиц и всегда видает достоверний результат. При етом доступно всем пользователям. Я даже не представляю сколько нужно потратисть усилий чтоб достичь такого результата самостоятельно.
4) Ну и в Pl/sql есть возможнось компиляции в нативний код.
Из минусов только GUI для C#/JAVA покруче и тесты писать сложнее. Отладка кода на БД ничем не хуже/сложнее чем в VS.
Да 100% писать код на C# или JAVA намного удобнее чем на PL/SQL за счет GUI синтаксиса и тд. Но когда задача работать с транзакциями и даними Pl/sql действительно хорош.
У каждой БД есть свои слабые и сильние стороны. И я считаю что PG лутшая из безплатных. Оракл — просто лутшая.
Если по сравнению pl/sql реально на порядок круче pgsql по возможностям, лаконичности, ориентации на быстодействие, и тд.
Из возможности БД — партиции явно еще не продакшин да и базових возможностей партиций на порядок меньше, такие фичи как кеш резалт — просто волшебная палочка.
Да и отсуствие merge. Оптимизатор намного круче и тд. Ето то что что пришло на ум за несколько минут. Да и скаждой новой версией Оракл не перестает удивлять.
Тут писали что t-sql крутой, для меня он реально топорний. Я с трудом представляю что кто то решится писать всю бизнес логику на t-sql или на pgsql. C ораклом на такое решится без проблем. Там управляемость и скорость, которою очень сложно достичь на высокоуровневых языках.
P.S. Неохота разводить холивар БЛ БД VS С\С+\C#\JAVA\…
citforum.ru/database/oracle/editions
Тригер на уровне операторов вообще зачетная вещь как и многоколоночная статистика.
Ну и партиции.
В целом PostgreSQL движется в правильном направлении.
Софтовий только в тел Siemens.
Круче поддержки небыло ни в какой другого производителя.
Досих пор живой E71 и EL71.
Там и мультизадачность и мультисим, аська и софта написано… И размер что надо.
Все кнопки настраивались.
У меня смартфон бил вторым телефоном годика так 3.
Разница в запросах + их оптимизация, не говоря уже о разнице pl/sql t-sql и pg/sql настолько огромная что ето фактически наново писать всю логику. То есть ето в принципе невозможно. А переход с версионника на блокировщик или наоборот ето еще то приключение, вплоть то переписивания логики приложения.
А то о чем вы говорите — ето способ писать приложения только используя SQL, а всю логику вне БД. При етом вы используете только незначительную часть возможности БД.
P.S. Была попотка перенести приложение c оракла на IBM DB2 которий декларировал совместимость pl/sql на 99%. Так от все вкусняшки по быстродействию оракла в pl/sql DB2 там не реализованы. Хотя я уверен есть свои. Оценив неоходимое время — мы отказались.
А по факту:
1) В класе версионник он отстал от оракла навсегда.
2) Партиции которие дают реальний прирост и маштабируемость появилось буквально в 10 версии и назвать что ето уже продакшин — как-то язик не поварачивается. Про in-memory в посгри я тоже ничего не слишал. (Оракл 12, MSSQL 2014). Пускай реализация местами странная и ограничений вагон и тележка но оно работает и дает реальний прирост.
Если правильно настроить базу и експлуатировать ее как она «любит» то на одном и том же железе разница может бить в процентах а не в разы.
«Рассуждение на тему, какую безплатную базу данных выбирать»
Если у вас есть деньги посмею дополнить:
MSSQL — мощная, легкая в администрировании.
ORACLE — наверное самая лутшая SQL БД з самим быстрим и мощным встроеним язиком PL/SQL (для любителей писать логику на БД)
Из недочотов — цена. Сложность администрирования.(с каждой новой реализацией становится проще)
Обе имеют Inmemory опции(очень разние по сути реализации).
Обе есть смисл покупать только в enterprise варианте, ибо вкусние плюшки только в enterprise редакции.
ноди Производительность относительно одной ноди
2 — 160%-180%
3 — 200%-240%
4- 240%-260%
При большем количестве смисл вообще терялся.
Поетому одна машина на power действительно лучше 2 нодовой x86 конфигурации.
статистикатесты. По каждому из тестов power показал в 3-4 кратное превосходство. + вопрос в качестве паралелизма в етих тестах. Ну и главное какое отношение ети тести имеют к производительности БД? Я писал что платфома имеет значение а не только сами ядра проца.Для примера. У нас был RAC с друх 2 сокетних x86 в каждом 4 реальних ядра (8- гипертрейдинг) 2*2*4 =16 ядер.
После перехода на 8 ядер power (Пез измений ПО, хранилища и версии БД) система стала на много отзивчивее. (без дополнительного тюнинга) После тюнинга прекрасно себя чувствовала на 4 ядрах. Я понимаю что прошло время и сейчас 20 ядер в сокете и тд… но не думаю что соотношение ядер сильно поменялось.
2) Но я всегда говорю что EXCEL ето програма которая наносит наибольший вред компаниям. Она отодвигает необходимую автоматизацию предприятий.
3) Ну и зделаю неблагодарную вещь, дам совет — Бегите с етого предприятия.
а) они в 2018 работали с бумажками.
б) они не поощрили увеличение производительности труда.
На таком предприятии работать безперспективно.
Но самое ужасное в том, что когда моя дочь поступила на один из лучшых тех вуз страны (Украина) Я узнал что в вузах практически ничего не поменялось. все тоже безобразное соотношение предметов математики и програмирования и теории к практике. Все те же глупые акценты и система оценивания. Причем среднее образование ничем не лучше. Но ето уже другая тема. :)
наибольшая табличка > 550 000 000 строк ежедевно увеличиваєтся 300 000 строк и ето не логи а таблица влияющая на остатки.