Осложненное добавление новой записи в БД

[alexs]

java73
Бывают и более страшные запросы. В каждом случае надо думать.
Mirage
Очень распространённое заблуждение.
Чем вызвана необходимость смены БД?

[Mirage]

Да хоть чем. Сейчас, в связи с импортозамещением, имеет место быть массовый переход со всяких ораклов и мсскюелов на PostgreSQL, например.
Продукт, над которым на работе работаю, должен поддерживать несколько СУБД, ибо не факт, что у заказчика будет именно та, что приглянулась нам, на этапе разработки. Это конкурентное преимущество. Потому и распространилось это "заблуждение".
А ORMы позволяют достаточно просто это обеспечить.

[java73]

А я вот не понимаю, чего все так хаят mysql. Никаких проблем с нею не было никогда, если изначально все правильно настроить. Вот в sqlite без потери точности данных и всех связей я перенести свою не смог. Для промышленных масштабов есть теперь конечно всякие azure, которые максимально интегрированы со всем микрософтским, ораклы и файрберды, но для web-мелкоты и для корпоративных инструментов mysql прекрасно подходит.

Бывают и более страшные запросы. В каждом случае надо думать.

Я хотел этим своим запросом показать, что вот так сейчас мне приходится через sql делать выборку данных для представления. при маппинге в объект это все упрощается до пары строк, поскольку разделение данных на два однородных но не идентичных объекта происходит на уровне конструктора. И тут вот как раз 2 сложности. Я пошел по пути первой. Делаю свой недо-слой ORM, который тупо в начале работы считывает всю базу в объекты, благо данных там не так уж и много, но есть картинки, для которых я придумываю способ ленивой загрузки. Второй путь - сидеть изучать готовые ORM, не хочу. mORMot очень далека от моих простых потребностей, tiOPF - для нее мне нужно будет все заново перелопатить, но зачем делать так, если все заново мне уже проще написать в entity framework.

[alexs]

что у заказчика будет именно та, что приглянулась нам, на этапе разработки.

Вы начинаете разработку до согласования этих вопросов с заказчиком????
А если тиражный коробочный продукт - то тут вообще заказчик курит.

Да хоть чем. Сейчас, в связи с импортозамещением, имеет место быть массовый переход со всяких ораклов и мсскюелов на PostgreSQL, например.

Вот это вообще не причина А отмазка для манагеров... При нормальном обосновании и оракл с mssql пропускают. А если супер-пупер фсб-но военная контора - то изначально что там эти комерческие продукты делали? Там ценник разработки другой и стоимость смены БД соверешенно не влияет на него.

А ORMы позволяют достаточно просто это обеспечить.

А то что ваш продукт из-за этих конструкторов не использует и 10% возможностей сервера, и в плане производительности более или менее серьёзные запросы дают просадку по скорости - это побоку?
Тогда можно как сбер сделать - н-звенку в которой клиент работает в IE строго прибитой версии и отчёты в которой формируются из этого ИЕ путём запуска строго определённого адобе реадера в котором тоже куча макросов которые кудато тоже лезут. Оно работает конечно - на вот как то странно

[serbod]

А я вот не понимаю, чего все так хаят mysql.

MySQL слишком простая для сервера, слишком сложная для клиента. Функционал не особо лучше, чем у SQLite, но при этом сложнее установка и обслуживание.

Делаю свой недо-слой ORM

Я таких самодельных ORMов уже штук 5 сделал, и не жалею. Разные задачи, в одних случаях первична структура объектов, а таблицы БД автоматически создаются под нее. В других случаях БД первична, и нужно под нее подстраиваться. Были случаи, когда приходилось оптимизировать запись в БД или совмещать ORM и хранимые процедуры.

[java73]

MySQL слишком простая для сервера, слишком сложная для клиента. Функционал не особо лучше, чем у SQLite, но при этом сложнее установка и обслуживание.

почему тогда пол интернета на ней работает и не падает?

[serbod]

А если супер-пупер фсб-но военная контора - то изначально что там эти комерческие продукты делали? Там ценник разработки другой и стоимость смены БД соверешенно не влияет на него.

У крутых госконтор с деньгами все непросто. Они могут потратить миллионы на какую-нибудь ненужную херню, типа крутейшего сервера размером с комнату, но дико экономить на софте, расходниках, разработчиках и обслуживающем персонале. Потому что разные статьи расходов, разные карманы. И нельзя просто взять из одного внутреннего кармана и переложить в другой внутренний карман. Сколько разного дорогущего железа пылится без дела из-за такого подхода..

Добавлено спустя 1 минуту 3 секунды:

почему тогда пол интернета на ней работает и не падает?

Потому что исторически сложилась классическая связка Apache - MySQL - PHP

[java73]

Сколько разного дорогущего железа пылится без дела из-за такого подхода

несите))))))))

Добавлено спустя 57 секунд:

Потому что исторически сложилась классическая связка Apache - MySQL - PHP

ну не из садомазохистских же потребностей web-разработчиков ведь.

[Mirage]

А если тиражный коробочный продукт - то тут вообще заказчик курит.

Ага, покурит и к конкуренту пойдет.

Вот это вообще не причина А отмазка для манагеров... При нормальном обосновании и оракл с mssql пропускают.

А зачем, если есть такая же СУБД, только бесплатная и открытым кодом.

А если супер-пупер фсб-но военная контора - то изначально что там эти комерческие продукты делали?

Открытость СУБД отнюдь не только спецслужбам нужна. Да и обстановка меняется.

Там ценник разработки другой и стоимость смены БД соверешенно не влияет на него.

Что за мифический ценник разработки, на который цена оракла не влияет? Особенно забавно без конкретных данных о размере БД, кол-ве разработчиков и т.п.
Лично общался с сотрудником одного из операторов большой тройки, который жаловался на непомерную стоимость оракла для них. Потому как у них данных много, а оракл дерет за каждое ядро. И таки да, собирались менять СУБД.

А то что ваш продукт из-за этих конструкторов не использует и 10% возможностей сервера, и в плане производительности более или менее серьёзные запросы дают просадку по скорости - это побоку?

А конкретнее? Что именно не используется? Какие запросы просаживаются и почему? Кстати, ОРМ может знать о специфичных расширениях языка SQL конкретной СУБД и использовать их.

Тогда можно как сбер сделать - н-звенку в которой клиент работает в IE строго прибитой версии и отчёты в которой формируются из этого ИЕ путём запуска строго определённого адобе реадера в котором тоже куча макросов которые кудато тоже лезут. Оно работает конечно - на вот как то странно

Общался с ребятами из Сбера, ни о чем таком не слышал. Хотя тяга к монструозным решениям есть, да и легаси всякого у них пока хватает, но они стали довольно продвинуты по технологиям.

[alexs]

покурит и к конкуренту пойдет

Такие продукты покупают ради функционала. А используемая внутри СУБД - это вообще дело десятое.
А если выбор вами базы существенно играет на цене вашего - то это уже ваша проблема.

А зачем, если есть такая же СУБД, только бесплатная и открытым кодом

Так это изначально ваша ошибка - необосновано использовать в начале разработки в продукте дорогое стороннее ПО, если есть вариант использовать бесплатные БД.

Что за мифический ценник разработки, на который цена оракла не влияет?

Спросите у ваших знакомых в сбере о цене системы делопроизводства. Там правда быд MS SQL (но он тоже не дёшев). Про внедрение и сопровождение лет 5 назад.

А конкретнее? Что именно не используется?

Основная претензия к ним с моей стороны - нет возможности выносить логику на сервер. Тригера, ХП никто не умеет. И те проверки и логику которую логичновести на уровне данных приходится выносить на уровень клиента (для трехзвенки - на 2-й слой)

[Mirage]

А если выбор вами базы существенно играет на цене вашего - то это уже ваша проблема.

Выбор собственно в том, чтобы СУБД можно было менять. В разумных пределах конечно.

Так это изначально ваша ошибка - необосновано использовать в начале разработки в продукте дорогое стороннее ПО, если есть вариант использовать бесплатные БД.

Тут все сложнее. Клиенты, это, как правило, крупные компании, возможно даже (полу)государственные. У кого-то стандарт на СУБД, т.е. использовать можно только ее, или их. У кого-то импортозамещение. И т.д. Гибкость тут явное преимущество.

Спросите у ваших знакомых в сбере о цене системы делопроизводства. Там правда быд MS SQL (но он тоже не дёшев). Про внедрение и сопровождение лет 5 назад.

Ну, Сбер он один такой. Остальные денежки таки считают. Да и Сбер считает.

Основная претензия к ним с моей стороны - нет возможности выносить логику на сервер.

Логика, она как правило, на сервере. На клиенте логику держать стремно как-то. Клиент отображать должен, не более. Но выбор СУБД тут не причем. Для логики есть бакенд.

Тригера, ХП никто не умеет. И те проверки и логику которую логичновести на уровне данных приходится выносить на уровень клиента (для трехзвенки - на 2-й слой)

Вызвать ХП, в принципе, ничто не мешает в том же Hibernate, но такого рода логика должна быть на бакенде. Для проверок констрейнты есть. Остальные - в бакенде.

[alexs]

Тут все сложнее. Клиенты, это, как правило, крупные компании, возможно даже (полу)государственные. У кого-то стандарт на СУБД, т.е. использовать можно только ее, или их. У кого-то импортозамещение.

Как-то трудно представить вот в этой ситуации коробочный продукт. Обычно эти клиенты требуеют индивидуально-заказное. И на этапе согласования утверждается требуемая СУБД.

Логика, она как правило, на сервере. На клиенте логику держать стремно как-то

Я подразумевал сервер СУБД - для него всё остальное - клиент. Т.е. не важно скольки звенка у вас. Для СУДБ ваш промежуточный сервер - тоже клиент.

но такого рода логика должна быть на бакенде. Для проверок констрейнты есть. Остальные - в бакенде.

Вот именно с этим я не согласен.
А чем констрайнт вам выделен? Почему другие проверки не делать тоже на сервере?
Да и некоторые расчётно-пересчётные части тоже прекрасно делаются на уровне сервера.
А уже всякие логи изменения данных - тут вообще все на уровне тригеров делается замечательно.

[Mirage]

Как-то трудно представить вот в этой ситуации коробочный продукт. Обычно эти клиенты требуеют индивидуально-заказное. И на этапе согласования утверждается требуемая СУБД.

Коробочный продукт это не обязательно коробка для домохозяек по 20 баксов. Лучше называть тиражируемым продуктом, у которого более одного клиента. И у этих клиентов могут быть разные СУБД.

А чем констрайнт вам выделен? Почему другие проверки не делать тоже на сервере?

Констрейнты это просто и более-менее стандартно.

Да и некоторые расчётно-пересчётные части тоже прекрасно делаются на уровне сервера.

Причин почему отказываются от логики в СУБД много. Навскидку - всю бизнес-логику в СУБД не засунешь, хотя многие пытались. А лучше когда логика в одном месте сконцентрирована.
Отсутствие вменяемых сред и тулчейнов тоже роляет. Мало кто хочет писать логику в каком-нибудь скюэлдевелопере. Хотят в Идее писать. И отлаживать.
В высоконагруженных продуктах БД, как правило, узкое место. Поэтому ее специально разгружают.

А уже всякие логи изменения данных - тут вообще все на уровне тригеров делается замечательно.

Когда-то делось. Сейчас между бакендом и СУБД кэши всякие. Так что тригером залогируется то, что дойдет до БД. Что разве что админам интересно.

[java73]

Фух, уже полтора года прошло!
В итоге я не ушел на C# )))
Зато перелопатил всю документацию разработчика TiOPF. Прокочегарил (сначала на кошках) все его примеры с использованием посетителей для маппинга из БД в объекты и назад, медиаторов и наблюдателей (кстати, в freepascal уже есть встроенный в TPersistent) и сейчас за пол месяца выпилил с нуля свою ORM, под конкретное приложение (да-да, то самое, с которого тема началась), с отрефакторинной базой данных.
Я свою проблему рекурсивного чтения из БД и вообще чтения решил так:
В начале создается менеджер данных (контекст), он управляет списками всех объектов, в которые мапятся данные из БД.
Отображение для просмотра и выбора записей происходит по-прежнему через DataSource и компоненты Zeos с помощью DBGrid, настроенной на определенный view из БД.
При раскрытии данных конкретной записи происходит чтение объекта из списка контекста или его создание и маппинг из БД, если его еще нет в списке, т.е. полноценная ленивая загрузка данных. Одновременно рекурсивно считываются все ассоциированные объекты.
Сохранение происходит схожим образом. Сначала по каждому объекту изменения накапливаются, потом сводятся менеджером и отправляются единым запросом на сервер.

[debi12345]

В БД "nextval(sequence)" обязательно вне транзакций (ни при каких условиях не откатывается), а "curravl(sequence)" в одном соединении не завиcит от вызовов "nextval(sequence)" в параллельных соединениях. Поэтому в пределах одного коннекта связка "nextval+ currval" - железобетонно-надежная.

Добавлено спустя 1 минуту 43 секунды:

В начале создается менеджер данных (контекст), он управляет списками всех объектов, в которые мапятся данные из БД.

Обычные библиотечные "красно-черные деревья"

Добавлено спустя 6 минут 40 секунд:

Вот в sqlite без потери точности данных и всех связей я перенести свою не смог

SQLITE3 тоже с нюансами. Например SQLITE3 в режиме "parameterized bulk insert" ничуть не быстрее манипуляций с EXCEL-файлами средствами VBA - если не включить единую транзакцию на все вставляемые записи.