Задумываюсь о создании своего набора компонентов для комфортной работы с БД (предполагаю поддержку пока только MySQL). Зачем нужно? Ну тут развернутый ответ. Есть вероятность что просто не умею работать правильно с БД, потому и вывешиваю данный пост здесь, народ чего скажет…
В бытность разработки приложения для учета оргтехники (обсуждение http://www.freepascal.ru/forum/viewtopic.php?f=10&t=7429) столкнулся со следующими проблемами:
-трудно отслеживать взаимосвязи между таблицами. Т.е. например удалил одну запись в какой-то таблице, нужно самому программно отслеживать чтоб были удалены все связанные записи в других таблицах.
-трудно реализуемо понятие «помечено на удаление». Все приходится отслеживать самому программно. Собственно потому в программе такое и не реализовал, гемор страшнейший.
-затруднительна работа с «блокировкой» записи, при многопользовательской работе. Возможно и есть что-то на уровне MySQL, но хотелось бы реализовать более внятно и понятно на уровне «да запись редактируется уже тем то и темто».
Что планирую реализовать:
-компонент который позволит создавать структуру БД и хранить оную (структуру) в XML файле. В нем будут описываться все взаимосвязи между таблицами.
компонент который будет использовать этот XML файл, и собственно будет «прослойкой» при работе с БД. Т.е. все запросы будут выполнятся через него. Как то, добавление, удаление,редактирование.
-прозрачно будет реализовано понятие «помечено на удаление». Т.е. например ставишь «помеченными на удаление» запись в таблице, все связанные записи тоже автоматически будут «помечены на удаление».
-точно также с «физическим» удалением записей. Все связанные записи будут удалены автоматически.
-упрощена работа с блокировками. При запросе редактирования/удаления компонент будет проверять редактируется эта таблица уже кем-то или нет.
Не хочется изобретать велосипед. Если нечто подобное уже где-то реализовано, ткните носом?
Фреймворк для работы с БД в Lazarus
Модератор: Модераторы
donpadlo писал(а):Т.е. например удалил одну запись в какой-то таблице, нужно самому программно отслеживать чтоб были удалены все связанные записи в других таблицах.
Код: Выделить всё
FOREIGN KEY ... ON DELETE CASCADEdonpadlo писал(а):трудно реализуемо понятие «помечено на удаление»
Код: Выделить всё
BEGIN TRANSACTON ... COMMITНужно ли? Нужнее было бы оповещение о чужих изменениях.donpadlo писал(а):затруднительна работа с «блокировкой» записи, при многопользовательской работе.
-
Brainenjii
- энтузиаст
- Сообщения: 1351
- Зарегистрирован: 10.05.2007 00:04:46
viewtopic.php?f=13&t=7038 - вот что у меня получается. Уже готов кодогенератор (для работы с Firebird'ом), общая структура "фреймворка" + куча планов на сетевую прозрачность и откат закоммиченных изменений и вообще много-много всего (причем планы более чем не сложно воплощаемы в жизнь ^_^)
Каждые выходные собираюсь оформить все наработки и выложить на форум, но собраться-то как раз не могу
Каждые выходные собираюсь оформить все наработки и выложить на форум, но собраться-то как раз не могу
вот нечто похожее. хотел попробовать но так и не дошли руки
Man Frames RAD Management Framework
Man Frames RAD Management Framework
-
alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
donpadlo
Не изобретайте велосипед. Возбмите любую хорошую книжку по РСУБД и почитайте - например по FireBird - http://www.firebirdsql.org/en/books/.
Там всё что вы хотите - уже есть.
А в качестве графического фронт-энда для разработки используем тот-же IBExpert.
А компоненты - это всего лишь средства для отображения данных. Не надо их логикой нагружать.
Не изобретайте велосипед. Возбмите любую хорошую книжку по РСУБД и почитайте - например по FireBird - http://www.firebirdsql.org/en/books/.
Там всё что вы хотите - уже есть.
А в качестве графического фронт-энда для разработки используем тот-же IBExpert.
А компоненты - это всего лишь средства для отображения данных. Не надо их логикой нагружать.
donpadlo писал(а):-компонент который позволит создавать структуру БД и хранить оную (структуру) в XML файле. В нем будут описываться все взаимосвязи между таблицами.
компонент который будет использовать этот XML файл, и собственно будет «прослойкой» при работе с БД. Т.е. все запросы будут выполнятся через него. Как то, добавление, удаление,редактирование.
-прозрачно будет реализовано понятие «помечено на удаление». Т.е. например ставишь «помеченными на удаление» запись в таблице, все связанные записи тоже автоматически будут «помечены на удаление».
-точно также с «физическим» удалением записей. Все связанные записи будут удалены автоматически.
Не хочется изобретать велосипед. Если нечто подобное уже где-то реализовано, ткните носом?
курить триггеры. Не нужно это в компоненты запихивать - это как минимум неправильно. Триггерами это всё реализуется элементарно.
Ну и кроме триггеров первое действительно можно:
Код: Выделить всё
FOREIGN KEY ... ON DELETE CASCADEа можно и тоже триггерами, тогда и условий всяких добавить можно будет.
Мое мнение:
1. Большинство функций, как-то пометка на удаление, связанное удаление, блокировки и прочее нужно реализовывать на самом SQL-сервере путем соответствующих SQL-запросов, триггеров и прочего.
2. НО! Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML). И эта конфигурация должна быть источником для автоматического составления SQL-запросов, триггеров и прочего. И эта же конфигурация использовалась для построения пользовательского интерфейса. Во-первых, это избавит от ошибок и противоречий в логике работы БД. Во-вторых, сильно упросит процесс развития самой БД в части добавления новых данных, полей, таблиц и т.п. Я сам нечто подобное использовал, но под некую конкретную бизнес-логику, т.е. решение не универсальное.
1. Большинство функций, как-то пометка на удаление, связанное удаление, блокировки и прочее нужно реализовывать на самом SQL-сервере путем соответствующих SQL-запросов, триггеров и прочего.
2. НО! Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML). И эта конфигурация должна быть источником для автоматического составления SQL-запросов, триггеров и прочего. И эта же конфигурация использовалась для построения пользовательского интерфейса. Во-первых, это избавит от ошибок и противоречий в логике работы БД. Во-вторых, сильно упросит процесс развития самой БД в части добавления новых данных, полей, таблиц и т.п. Я сам нечто подобное использовал, но под некую конкретную бизнес-логику, т.е. решение не универсальное.
alexey38 писал(а):Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML).
Изобрести велосипед?
Я про CASE-системы для СУБД.
donpadlo
Для JAVA есть такой фреймворк Hibernate. В рамках этого проекта была разработана подсистема JPA 1.0 Немножко громоздкая и не очень удобная. Следующая ее спецификация была разработана в рамках проекта EclipseLink. Чтобы не изобретать велосипед, посмотрите как реализовано в EclipseLink (JPA 2.0) http://www.eclipse.org/eclipselink/jpa.php
ЗЫ. Для того кто работает с паскалем JAVA код не составит труда для чтения.
Для JAVA есть такой фреймворк Hibernate. В рамках этого проекта была разработана подсистема JPA 1.0 Немножко громоздкая и не очень удобная. Следующая ее спецификация была разработана в рамках проекта EclipseLink. Чтобы не изобретать велосипед, посмотрите как реализовано в EclipseLink (JPA 2.0) http://www.eclipse.org/eclipselink/jpa.php
ЗЫ. Для того кто работает с паскалем JAVA код не составит труда для чтения.
sign писал(а):alexey38 писал(а):Удобно было в одном месте описать бизнес-логику приложения в части работы с БД - назовем это конфигурацией (м.б. в XML).
Изобрести велосипед?
Я про CASE-системы для СУБД.
Я не говорил про то, что все нужно писать с нуля, и что вообще нужно что-то писать. Я описал тот функционал, который на мой взгляд целесообразен. Ведь обычно перед выбором средства реализации определяются задачи и функции.
Что касается CASE-систем, то мировой опыт их применения показал ограниченность их в части применения. CASE-системы хороши, когда идет централизованная разработка, но они не применимы, когда изменение структуры БД осуществляется самим пользователем. Практика обычно находиться где-то посередине. Для определенного уровня гибкости нет необходимости менять код программы, т.е. перекомпиляция проекта не требуется. Из этой же оперы - скрипты. Ведь от них также можно было бы отказаться, и любой код компилировать. Но скрипты дают гибкость, не нужно таскать с собой среду программирования.
Что касается фреймворка для паскаля, то подсказать не могу. Но в свое время еще примерно в 1994-95 годах делал нечто подобное, интернета тогда не было, так что велосипед приходилось изобретать много в чем. В последнее время подобное делал, но все было завязано на модель предметной области, которая и являлась конфигурацией БД - подход универсальный, но реализация под частный случай.
alexey38 писал(а):Что касается CASE-систем, то мировой опыт их применения показал ограниченность их в части применения. CASE-системы хороши, когда идет централизованная разработка, но они не применимы, когда изменение структуры БД осуществляется самим пользователем.
ЛПП
Всегда работал с CASE. Это наиболее удобное средство для разработки в том числе и мною одним
Для MySQL лучшее - распространяется бесплатно самим mysql Называется MySQL Worbench
tema писал(а):alexey38 писал(а):Что касается CASE-систем, то мировой опыт их применения показал ограниченность их в части применения. CASE-системы хороши, когда идет централизованная разработка, но они не применимы, когда изменение структуры БД осуществляется самим пользователем.
ЛПП
Всегда работал с CASE. Это наиболее удобное средство для разработки в том числе и мною одним
Для MySQL лучшее - распространяется бесплатно самим mysql Называется MySQL Worbench
Workbench - не плохой инструмент сам использовал. Вы в принципе подтвердили, что CASE применяется при централизованной разработке, а разработка одним человеком - это высшая степень централизации (все в одних руках).
Но когда у Вас будут 10, 50, 100, 1000, 10000 и более клиентов, каждый из которых правит структуру БД, то Вы сойдете с ума от CASE, они такого там нагородят, что ничего не будет работать. Банальный пример - 1С, все именно так и происходит (но там нет CASE). Вот для таких случаев, отдельная конфигурация БД, узкоспециализированный конфигуратор БД, и фреймворк работающий с БД через конфигурацию БД - это все неизбежная реальность. Без этого вообще ни как.