Проектирование БД

← →
bss (2010-10-22 00:04) [0]

Ребят, а кто как проектирует структуры и данные БД?
Особо интересны мнения тех, кто участвовал в более-менее крупных проектах (от 100 таблиц).

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

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

Делать все изменения в БД, а потом раз в N"ое количество времени делать реверс - тоже не самое кошерное. Во-первых, автоматический реверс чисто визуально (на уровне квадратиков и линий между ними) выглядит фигово, смотрибильно это может сделать только человек, но делать это каждый раз при реверсе - титанический труд. Во-вторых, не всегда понятно, что нужно реверсить. Обычно в develop-базе куча всякого лишнего.

Все косяки наблюдаются при внедрении. Обычно есть девелоперская база, в ней все работает, конечно. Полностью перетащить ее в тестовую базу (а соответственно, потом и на боевую) не представляется разумным из-за мусора и всяческих левых фишек. Развернуть на тестовой базе структуру из CASE-средства - вариант, но из-за этой самой рассинхронизации что-то не будет работать. На этом этапе надо проводить полное тестирование и убирать как раз косяки расхождения необходимой структуры базы с той, что есть в CASE. Но опять же идеально провести этот процесс чрезвычайно сложно :-(

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

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

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

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

Уффф, спасибо за внимание :-)

← →
Германн © (2010-10-22 02:42) [1]

"Как пройти в библиотеку?
В три часа ночи! Идиот."
(с) Операция Ы

← →
Аноним (2010-10-22 07:14) [2]

ручка с бумажкой
5-10 баз, 100-300 таблиц

← →
Sergey Masloff (2010-10-22 08:31) [3]

Добиваться соответствия CASE с реальной базой - не нужно. Затраты на это дело превысят выгоды.
В кейсе можно держать концептуальную модель, логику организации данных. На фига там сами триггеры и хранимки - не знаю.
Все ИМХО

P.S. база 8 тыс объектов (таблицы, вьюхи, пакеты, очереди...) Таблиц примерно 700. 2 млн. строк серверного кода. CASE используется только как заменитель листка бумажки с карандашом для описания логических связей.
Проблем с разворачиванием нет.

← →
sniknik © (2010-10-22 09:52) [4]

> Приветствуются хорошие статьи на эту тему
вот хорошая статья
http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html
немного не в тему, но по сути, о том, что ты чаще всего учишь не то, что тебе реально нужно, а представления других об этом, реализованные в виде надстройки над этим/"помощника".

← →
Sergey Masloff (2010-10-22 10:10) [5]

sniknik © (22.10.10 09:52) [4]
Не нравится мне Джоел. Но эта статейка неплохая

← →
Игорь Шевченко © (2010-10-22 10:12) [6]

> Особо интересны мнения тех, кто участвовал в более-менее
> крупных проектах (от 100 таблиц).
>
> На определенном этапе держать в голове структуру БД становится
> занятием бесполезным, поэтому желательно наглядное визуальное
> представление в каком-нибудь CASE-средстве.

Визуальное представление для большой базы более чем бесполезно. Равно как и визуальное представление большого количества классов в виде диаграмм

← →
boriskb © (2010-10-22 10:27) [7]

> вот хорошая статьяhttp://russian.joelonsoftware.com/Articles/LeakyAbstractions.
> html

Действительно хорошая.
С точки зрения методики преподавания.
Хоть чего :))

← →
DVM © (2010-10-22 10:48) [8]

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

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

← →
lucent (2010-10-22 11:36) [9]

Sergey Masloff (22.10.10 08:31) [3]

>Таблиц примерно 700

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

← →
Inovet © (2010-10-22 12:15) [10]

> [8] DVM © (22.10.10 10:48)
> По крайней мере у процессоров интел ее никогда не было.
> Были схемы для небольших узлов, но всего процессора не было

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

Но почему это не схема? Это и есть схема. О Интел: насколько знаю, макет Пентиум был сделан на отдельных микросхемах на нескольких печатных платах, теперь моделируется. Опять же, а как без полной схемы моделировать работу? - ну отдельные блоки сначала, потом заменить их на чёрные ящики и уже следующий уровень.

← →
bss (2010-10-22 12:41) [11]

> Добиваться соответствия CASE с реальной базой - не нужно.
> Затраты на это дело превысят выгоды

аналогичное мнение

> На фига там сами триггеры и хранимки - не знаю

чтобы иметь возможность развернуть базу из кейса.

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

То есть, делать слепок с девелоперской базы не разумно, так как там всегда куча мусора. В модели не полное представление. Собственно, вопрос - откуда разворачивать базу? Зачастую составляют ручками некий скрипт, который и производит развертывание БД. Но со временем он становится гигантоподобным. Разобраться в этих мегабайтах текста просто не представляется возможным, а зачастую логика развертывания зависит от последовательности развертывания.

Также любопытен вопрос как вы осуществляете доработку? Каждый разработчик составляется скрипты DDL и кто-то занимается опять же их внесением в один огромный скрипт? А для переходов с каждой версии на следующую делается локальный переходный скрипт?

В общем, интересен процесс разработки, что конкретно делает тот человек, который создает / модифицирует БД, куда это записывает. Каким образом происходит разворачивание системы и ее модификация.

> CASE используется только как заменитель листка бумажки с
> карандашом для описания логических связей.

ну например, добавили поле являющееся ссылкой на запись в другой таблице (FK). Что происходит - разработчик это добавляет в базе, составляет необходимый скрипт - отсылает его тому, кто следит за логикой БД и плюс еще модифицирует схему кейсе (чтобы показать новую связь)?

> Визуальное представление для большой базы более чем бесполезно

ну речь не идет о визуальном представлении всей БД, это не смотрибельно, конечно. Проект все равно делится на подпроекты и в схеме содержится своя подчасть.

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

← →
bss (2010-10-22 13:01) [12]

В целом, интересует кто какую логику работы использует:

1) каким образом составляется первоначальная версия продукта. Человек проектирует БД ручками, потом повторяет тоже самое в кейсе?
Проектирует в кейсе, дальше разворачивает это на БД?

Каким образом составляется кейс, который может развернуть всю БД?
Или каким образом составляется скрипт, который разворачивает БД?

2) как происходит переход на новые версии, куча скриптов объединяются ручками в переходной скрипт и параллельно добиваются в один главный скрипт, который разворачивает актуальную версию БД?

При ведении полной модели в кейсе можно сделать merge между двумя версиями и получить скрипт изменения. Причем это можно сделать для перехода с любой версии на любую.
С данными сложнее, конечно...

← →
lucent (2010-10-22 13:07) [13]

>Собственно, вопрос - откуда разворачивать базу?

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

>в один огромный скрипт?

Для этого обычно используют Issue Management системы с ветками для различных заказчиков, где документируется, что за изменения, для чего они нужны. Все скрипты затем накатываются на эталонный образ.

← →
Sergey Masloff (2010-10-22 13:17) [14]

lucent (22.10.10 11:36) [9]
>Sergey Masloff (22.10.10 08:31) [3]
Судя по стилю изложения предположу, что о ORM я рассказывал студентам еще в ту светлую пору когда вы посещали дошкольные учебные заведения
;-)

← →
Игорь Шевченко © (2010-10-22 13:22) [15]

> В целом, интересует кто какую логику работы использует:

вот у нас таблиц много (присутствующие не дадут соврать). Все сделано преимущественно руками. И ничего :)

Делается схема-зародыш, из нее дамп, в случае необходимости этот дамп разворачивается.

← →
Sergey Masloff (2010-10-22 13:30) [16]

bss (22.10.10 13:01) [12]
>В целом, интересует кто какую логику работы использует:

>1) каким образом составляется первоначальная версия продукта. Человек >проектирует БД ручками, потом повторяет тоже самое в кейсе?
>Проектирует в кейсе, дальше разворачивает это на БД?

В кейсе не проектирует. Проектирует на бумажке и вживую, в кейс (если считает нужным) вносит общие (на макроуровне) схемы

>Каким образом составляется кейс, который может развернуть всю БД?
>Или каким образом составляется скрипт, который разворачивает БД?
Никаким. Не разворачиваем базу из кейса

>2) как происходит переход на новые версии, куча скриптов объединяются >ручками в переходной скрипт и параллельно добиваются в один главный >скрипт, который разворачивает актуальную версию БД?
Есть перехватчик который журналирует весь DDL (на самом деле у нас и весь DML) этот DML потом проигрывается на target системах (не весь естественно а в соответствии с правилами).

Смысла в заливке из скрипта не вижу, делаем через экспорт-импорт

По веткам не понял проблему. У вас у разных "заказчиков" разные DDL? У нас такого нет поэтому не могу сказать на эту тему ничего

← →
Sergey Masloff (2010-10-22 13:31) [17]

Игорь Шевченко © (22.10.10 13:22) [15]
Тоже про нанотехнологии небось не знаете... Все по старинке ;-)

← →
MsGuns © (2010-10-22 13:41) [18]

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

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

И вообще, искусство проектирования баз данных не менее "заумно" (и, кстати, интересно), чем разработка тех же компилляторов или ОС

← →
lucent (2010-10-22 13:48) [19]

MsGuns © (22.10.10 13:41) [18]

По сути, сложность БД определяется сложностью модели. Но как мы видим, модель можно реализовать сложно и неудобно, а можно просто и относительно удобно. Если конечно поддержка в средствах работы с БД на стороне клиента позволяет обеспечить такое удобство. Дельфи в этом плане остался в каменном веке и потокает велосипедостроению, насколько я понимаю, по сравнению с тем, что есть у более современных средств разработки.

← →
MsGuns © (2010-10-22 13:52) [20]

Судя по [12] автора волнует проблема сопровождения и модернизации БД, но не собственно разработка. При условии, что проектировщик-исполнитель "сидит" отдельно от пользователя-заказчика, а доработка БД продолжительна по времени и существенна по объемам, у него в полный рост встает проблема "переноса" тудой-сюдой как модели БД, так и компонент бизнес-логики.
Автор пытается решить эту проблему соответсвующим кейс-средством, прекрасно понимая, что это не панацея.

Где выход ?

А его нету. Точнее их масса, но все они в общем случае ведут неизвестно к чему.

Думается, что одним из не самых плохих решений в этом направлении является решительный переход на объектную модель БД. При наличии хорошего инструмента - быстрее и комфортнее. Без такового - разработка собственного. Учитывая, что поднятая проблема характерна для солидных проектов (в т.ч. и по критериям "время" и "деньги"), затраченные усилия не выглядят неэффективными, наоборот - позволят избавится от львиной доли проблем, связанных с примененим обычной, "плоской" технологии.

← →
Sergey Masloff (2010-10-22 13:56) [21]

lucent (22.10.10 13:48) [19]

При чем здесь вообще дельфи? (Кроме того что это сайт по Дельфи)?

И какие такие революционные средства появились (в пока не озвученых) современных средствах? Спрашиваю серьезно, интересно. Я уже довольно долгое время занимаюсь только B2B проектами в которых никакого клиентского кода нет по определению, и, возможно, отстал от жизни. Но судя по некоторым косвенным признакам революции пока таки не произошло.

← →
Sergey Masloff (2010-10-22 13:58) [22]

MsGuns © (22.10.10 13:52) [20]
Что есть объектная модель БД в данном контексте?

← →
MsGuns © (2010-10-22 13:59) [23]

>lucent (22.10.10 13:48) [19]
>Если конечно поддержка в средствах работы с БД на стороне клиента позволяет обеспечить такое удобство.

А кто определяет системное клиентское ПО СУБД, как не проектировщик этого СУБД ? Если к самой системе надо еще поставлять кучу сервиса, к тому же еще и не бесплатного, то кто доктор тому проектировщику ?
Или тому, кто платит такому проектировщику, соглашаясь на все его требования ?

>Дельфи в этом плане остался в каменном веке и потокает >велосипедостроению, насколько я понимаю, по сравнению с тем, что есть >у более современных средств разработки.

Вот мне не понятны такие вот сравнения. Кто и когда выставлял Делфи инструментом проектирования баз данных ?

← →
MsGuns © (2010-10-22 14:07) [24]

>Sergey Masloff (22.10.10 13:58) [22]
>Что есть объектная модель БД в данном контексте?

Странно слышать от :)
Масса статей в инете. Куча реализаций на практике.
Если кратко - сама база представляет "вовне" не таблицы с полями, а ОБЪЕКТЫ, имеющие набор характеристик, объединенные между собой связями - отношениями. Изменение любого объекта или любой его характеристики приводит к автоматической перестройки всей модели, в том числе и в клиентской части (формы, отчеты, диалоги)
"Апгрейд" такой базы выполняется по заложенному в нее алгоритму, инкапсулированному в те же объекты

Сразу скажу, что сколь-нибудь приличного опыта работы с объектными БД не имею. Просто доводилось встречаться с такими, в том числе при установке апдейтов. Поражал "интеллект" системы, корректно перестраивавшей все данные полностью в автоматическом режиме

← →
Думкин © (2010-10-22 14:13) [25]

> Sergey Masloff (22.10.10 13:56) [21]

да, тролль это - причем не особо умный.

← →
Sergey Masloff (2010-10-22 14:14) [26]

MsGuns © (22.10.10 14:07) [24]
Я просто хотел уточнить что именно ты имеешь в виду ;-)
Теперь понятно.

Не я из "объектных" БД щупал кэши и что-то не проникся. А так живых систем на них не видел, чего скрывать...

← →
Игорь Шевченко © (2010-10-22 14:27) [27]

Sergey Masloff (22.10.10 13:31) [17]

> Тоже про нанотехнологии небось не знаете...

И про нанотехнологии не знаем, и CASE-ами не пользуемся, и объектными возможностями не пользуемся, а вот тем не менее живет себе система.

← →
lucent (2010-10-22 14:43) [28]

Sergey Masloff (22.10.10 13:56) [21]

Объектная структура вполне хорошо эмулируется в реляционной БД (уже описанным введением таблиц "Классы"->"Экземпляры классов", "Поля" -> "Значения полей"), при этом, нужно поддерживать ограниченное количество связей и констрейнтов, в отличие от случая с созданием на каждую сущность своей таблицы. А современные средства разработки (те же (N)Hibernate/Spring), в купе со средствами реверсинжиниринга (к примеру, JBoss Hibernate Tools) позволяют почти одним нажатием кнопки натянуть на это дело прокси-объекты для работы на клиенте (ну если уж полностью делать маппинг модели данных на прокси-объекты, то в этом случае реализацию объектов для конкретных сущностей придется писать руками, хотя можно сгенерировать по CASE-модели сущностей, если она есть). В Дельфи такое реализовано?

> lucent (22.10.10 14:43) [28]

> В Дельфи такое реализовано?

Причем тут Delphi? О нем не было даже упоминаний.

lucent (22.10.10 14:43) [28]

"Довольно часто встречаются приложения, построенные с использованием универсальных моделей данных для максимальной гибкости, и приложения, построенные так, что они мешают работе. Например, хорошо известно, что можно представить любой объект в базе данных используя только четыре таблицы:

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт "Эффективное проектирование приложений Oracle"

Учить наизусть!

← →
lucent (2010-10-22 15:13) [31]

Игорь Шевченко © (22.10.10 14:56) [30]

>Не используется словарь данных и метаданные. Те, кто применяет универсальный подход, загоняют себя в угол.

В угол как раз загоняют себя те, кто всегда использует прямой подход, ибо универсальная модель позволяет динамически изменять объектную модель, без изменения структуры БД вообще (в действительно сложных системах это может быть необходимо, и я лично работал с такой системой, которая, на удивление - функционировала относительно неплохо).
А что до производительности, то нужно понимать, что это tradeoff. Очень безапеляционное выссказывание вы привели.

> Очень безапеляционное выссказывание вы привели.

Такова жизнь. В верности этого высказывания убеждается с каждым разом все большее количество разработчиков, наступающих на грабли универсальности. Некоторые умудряются наступать по несколько раз.

← →
Sergey Masloff (2010-10-22 15:37) [33]

lucent (22.10.10 14:43) [28]
Этот подход имеет известные проблемы с масштабированием. У меня сейчас в самых "длинных" таблицах число записей под миллиард ;-) Разворачивание их в объектную структуру равнозначно увеличению этого числа на порядок минимум. Эффективная работа с таким объемом будет затруднена, организовать (эффективно) индексирование и партиционирование будет нетривиальной задачей. Хотя полностью этот подход я отрицать не склонен.

С hibernate я знаком много лет, также (уже меньше) знаю его потомка NHibernate. Мне подход не нравится. Это идеология одиночных операций и работы с копиями объектов - она даже для чистого OLTP не всегда хороша а где в нашей жизни чистота...
Я как-то не проникся.

> DVM (22.10.2010 10:48:08) [8]

Была, я видел фото - метров 100 в длину и 6 в высоту (транзисторы
нарисованы).

> [34] Anatoly Podgoretsky © (22.10.10 15:57)
> Была, я видел фото - метров 100 в длину и 6 в высоту (транзисторы нарисованы).

У Интел? Так я и говорю, в чём проблема её сделать, лна же есть в их САПР, ну печатать - это уже прикол для рекламы там, книги рекордов Гинесса.

Не помню откуда узнал, может и деза. В какие-то уже далёкие годы для Майкрософт изготовили плотер, допустим Хьюлет Пакард, шириной 10 метров, для вывода блок схем их ОС.

> Inovet (22.10.2010 16:19:35) [35]

У Интел, по телевизору показывали. Процессор был P IV

> bss
> > Добиваться соответствия CASE с реальной базой - не нужно.
> > Затраты на это дело превысят выгоды
> аналогичное мнение

эээ... Вы это серьёзно? Хотите сказать то, что Вы делаете и то, что получается - в принципе не одно и то же? И Вы никак не можете проверить/гарантировать соответствия? Как понял, здесь речь идёт о неком подобии модуля schema http://drupal.org/project/schema Насчет тысяч таблиц не знаю, но на сотнях летает...

> что конкретно делает тот человек, который создает / модифицирует
> БД, куда это записывает. Каким образом происходит разворачивание
> системы и ее модификация.

друпал твоё всё, там это уже давно решено: и установка, и модификация, и выполнение "долгих" "удалённых" инсталляций... ;)

← →
Лукошко (2010-10-22 17:40) [38]

delphimaster.ru
"Причем тут Delphi?"

Просто улыбнуло пятничным вечером :o)

> [36] Anatoly Podgoretsky © (22.10.10 16:37)
> У Интел, по телевизору показывали. Процессор был P IV

Это размер транзистора на чертеже 100 * 6 / порядка 10**9 = около 1 мм. Круто.

← →
bss (2010-10-22 18:14) [40]

> откуда разворачивать базу?
>
> Из эталонного образа

абсолютно ненужный ответ. Хорошо, каким образом составляется эталонный образ?

> Проектирует на бумажке и вживую, в кейс (если считает нужным)
> вносит общие (на макроуровне) схемы

То есть, в кейсе у вас нету непосредственно структуры таблиц? Нет непосредственных связей одной таблицы с другой?

> >Каким образом составляется кейс, который может развернуть
> всю БД?
> >Или каким образом составляется скрипт, который разворачивает
> БД?
> Никаким. Не разворачиваем базу из кейса

ну так я два варианта предложил. Или из кейса разворачивать, или из некоего скрипта. Как еще?
В кейсе вы не ведете - я понял.

Тогда каким образом составляется общий скрипт развертывания базы?

> Есть перехватчик который журналирует весь DDL (на самом
> деле у нас и весь DML) этот DML потом проигрывается на target
> системах (не весь естественно а в соответствии с правилами).
>

хм, интересно... Невозможно принять девелоперскую базу за эталон именно по причине мусора, как в структуре данных, так и самих данных.

В твоем случае проще сравнить девелоперскую БД с БД предыдущей версии и получить скрипты непосредственно перехода. Перехватывая DDL вы еще и таким образом формируете историю изменения метаданных. Простой пример, завели табличку, потом поняли что не нужна - дропнули. При сравнении эталона с девелоперской ничего и не будет, в вашем подходе вы перехватите CREATE TABLE, а потом ее DROP.

И все таки как вы отличаете мусорные данные (не требующие переноса на эталон) от необходимых для перехода данных? Очень интересует про эти "в соответствии с правилами".
Опять же, если есть правила - проще сравнить две БД и увидеть именно актуальные изменения. А если вы перехватываете все DDL...

> Смысла в заливке из скрипта не вижу, делаем через экспорт-
> импорт

импорт экспорт чего? Не понимаю о чем ты говоришь...
Я основываюсь на том, что в девелоперской базе много всякого мусора, именно это и мешает ее использовать. Может быть, вы как-то избегаете этого?

Проектирование БД Найти похожие ветки