Фреймворк для работы с БД в Lazarus

[donpadlo]

Задумываюсь о создании своего набора компонентов для комфортной работы с БД (предполагаю поддержку пока только MySQL). Зачем нужно? Ну тут развернутый ответ. Есть вероятность что просто не умею работать правильно с БД, потому и вывешиваю данный пост здесь, народ чего скажет…

В бытность разработки приложения для учета оргтехники (обсуждение http://www.freepascal.ru/forum/viewtopic.php?f=10&t=7429) столкнулся со следующими проблемами:

-трудно отслеживать взаимосвязи между таблицами. Т.е. например удалил одну запись в какой-то таблице, нужно самому программно отслеживать чтоб были удалены все связанные записи в других таблицах.
-трудно реализуемо понятие «помечено на удаление». Все приходится отслеживать самому программно. Собственно потому в программе такое и не реализовал, гемор страшнейший.
-затруднительна работа с «блокировкой» записи, при многопользовательской работе. Возможно и есть что-то на уровне MySQL, но хотелось бы реализовать более внятно и понятно на уровне «да запись редактируется уже тем то и темто».


Что планирую реализовать:

-компонент который позволит создавать структуру БД и хранить оную (структуру) в XML файле. В нем будут описываться все взаимосвязи между таблицами.
компонент который будет использовать этот XML файл, и собственно будет «прослойкой» при работе с БД. Т.е. все запросы будут выполнятся через него. Как то, добавление, удаление,редактирование.
-прозрачно будет реализовано понятие «помечено на удаление». Т.е. например ставишь «помеченными на удаление» запись в таблице, все связанные записи тоже автоматически будут «помечены на удаление».
-точно также с «физическим» удалением записей. Все связанные записи будут удалены автоматически.
-упрощена работа с блокировками. При запросе редактирования/удаления компонент будет проверять редактируется эта таблица уже кем-то или нет.

Не хочется изобретать велосипед. Если нечто подобное уже где-то реализовано, ткните носом?

[v-t-l]

Т.е. например удалил одну запись в какой-то таблице, нужно самому программно отслеживать чтоб были удалены все связанные записи в других таблицах.

Код: Выделить всё

FOREIGN KEY ... ON DELETE CASCADE

трудно реализуемо понятие «помечено на удаление»

Код: Выделить всё

BEGIN TRANSACTON ... COMMIT

затруднительна работа с «блокировкой» записи, при многопользовательской работе.

Нужно ли? Нужнее было бы оповещение о чужих изменениях.

[Brainenjii]

viewtopic.php?f=13&t=7038 - вот что у меня получается. Уже готов кодогенератор (для работы с Firebird'ом), общая структура "фреймворка" + куча планов на сетевую прозрачность и откат закоммиченных изменений и вообще много-много всего (причем планы более чем не сложно воплощаемы в жизнь ^_^)
Каждые выходные собираюсь оформить все наработки и выложить на форум, но собраться-то как раз не могу

[ViTality]

вот нечто похожее. хотел попробовать но так и не дошли руки
Man Frames RAD Management Framework

[alexs]

donpadlo
Не изобретайте велосипед. Возбмите любую хорошую книжку по РСУБД и почитайте - например по FireBird - http://www.firebirdsql.org/en/books/.
Там всё что вы хотите - уже есть.
А в качестве графического фронт-энда для разработки используем тот-же IBExpert.
А компоненты - это всего лишь средства для отображения данных. Не надо их логикой нагружать.

[tema]

-компонент который позволит создавать структуру БД и хранить оную (структуру) в XML файле. В нем будут описываться все взаимосвязи между таблицами.
компонент который будет использовать этот XML файл, и собственно будет «прослойкой» при работе с БД. Т.е. все запросы будут выполнятся через него. Как то, добавление, удаление,редактирование.
-прозрачно будет реализовано понятие «помечено на удаление». Т.е. например ставишь «помеченными на удаление» запись в таблице, все связанные записи тоже автоматически будут «помечены на удаление».
-точно также с «физическим» удалением записей. Все связанные записи будут удалены автоматически.

Не хочется изобретать велосипед. Если нечто подобное уже где-то реализовано, ткните носом?

курить триггеры. Не нужно это в компоненты запихивать - это как минимум неправильно. Триггерами это всё реализуется элементарно.
Ну и кроме триггеров первое действительно можно:

Код: Выделить всё

FOREIGN KEY ... ON DELETE CASCADE

а можно и тоже триггерами, тогда и условий всяких добавить можно будет.

[alexey38]

Мое мнение:
1. Большинство функций, как-то пометка на удаление, связанное удаление, блокировки и прочее нужно реализовывать на самом SQL-сервере путем соответствующих SQL-запросов, триггеров и прочего.

2. НО! Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML). И эта конфигурация должна быть источником для автоматического составления SQL-запросов, триггеров и прочего. И эта же конфигурация использовалась для построения пользовательского интерфейса. Во-первых, это избавит от ошибок и противоречий в логике работы БД. Во-вторых, сильно упросит процесс развития самой БД в части добавления новых данных, полей, таблиц и т.п. Я сам нечто подобное использовал, но под некую конкретную бизнес-логику, т.е. решение не универсальное.

[sign]

Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML).

Изобрести велосипед?
Я про CASE-системы для СУБД.

[vada]

donpadlo
Для JAVA есть такой фреймворк Hibernate. В рамках этого проекта была разработана подсистема JPA 1.0 Немножко громоздкая и не очень удобная. Следующая ее спецификация была разработана в рамках проекта EclipseLink. Чтобы не изобретать велосипед, посмотрите как реализовано в EclipseLink (JPA 2.0) http://www.eclipse.org/eclipselink/jpa.php
ЗЫ. Для того кто работает с паскалем JAVA код не составит труда для чтения.

[alexey38]

Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML).

Изобрести велосипед?
Я про CASE-системы для СУБД.

Я не говорил про то, что все нужно писать с нуля, и что вообще нужно что-то писать. Я описал тот функционал, который на мой взгляд целесообразен. Ведь обычно перед выбором средства реализации определяются задачи и функции.

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

Что касается фреймворка для паскаля, то подсказать не могу. Но в свое время еще примерно в 1994-95 годах делал нечто подобное, интернета тогда не было, так что велосипед приходилось изобретать много в чем. В последнее время подобное делал, но все было завязано на модель предметной области, которая и являлась конфигурацией БД - подход универсальный, но реализация под частный случай.

[tema]

Что касается CASE-систем, то мировой опыт их применения показал ограниченность их в части применения. CASE-системы хороши, когда идет централизованная разработка, но они не применимы, когда изменение структуры БД осуществляется самим пользователем.

ЛПП
Всегда работал с CASE. Это наиболее удобное средство для разработки в том числе и мною одним
Для MySQL лучшее - распространяется бесплатно самим mysql Называется MySQL Worbench

[alexey38]

Что касается CASE-систем, то мировой опыт их применения показал ограниченность их в части применения. CASE-системы хороши, когда идет централизованная разработка, но они не применимы, когда изменение структуры БД осуществляется самим пользователем.

ЛПП
Всегда работал с CASE. Это наиболее удобное средство для разработки в том числе и мною одним
Для MySQL лучшее - распространяется бесплатно самим mysql Называется MySQL Worbench

Workbench - не плохой инструмент сам использовал. Вы в принципе подтвердили, что CASE применяется при централизованной разработке, а разработка одним человеком - это высшая степень централизации (все в одних руках).

Но когда у Вас будут 10, 50, 100, 1000, 10000 и более клиентов, каждый из которых правит структуру БД, то Вы сойдете с ума от CASE, они такого там нагородят, что ничего не будет работать. Банальный пример - 1С, все именно так и происходит (но там нет CASE). Вот для таких случаев, отдельная конфигурация БД, узкоспециализированный конфигуратор БД, и фреймворк работающий с БД через конфигурацию БД - это все неизбежная реальность. Без этого вообще ни как.