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

← →
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-модели сущностей, если она есть). В Дельфи такое реализовано?

← →
DVM © (2010-10-22 14:52) [29]

> lucent (22.10.10 14:43) [28]

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

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

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

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. Очень безапеляционное выссказывание вы привели.

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

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

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

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

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

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

← →
Anatoly Podgoretsky © (2010-10-22 15:57) [34]

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

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

← →
Inovet © (2010-10-22 16:19) [35]

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

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

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

← →
Anatoly Podgoretsky © (2010-10-22 16:37) [36]

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

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

← →
xayam © (2010-10-22 16:43) [37]

> 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...

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

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

← →
bss (2010-10-22 18:20) [41]

> Хотите сказать то, что Вы делаете и то, что получается -
> в принципе не одно и то же?

не понял вопроса

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

это какой-то модуль к какой-то CMS системе как я понял. Как это связано с задачей?

Или там реализованы какие-то принципы? Можно рассказать тогда об этим принципах?

> Inovet (22.10.2010 18:03:39) [39]

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

← →
Sergey Masloff (2010-10-22 18:44) [43]

bss (22.10.10 18:14) [40]
Извини, мне кажется ты нарисовал какую-то свою картину и просто пытаешься читать только то что с ней совпадает ;-)

>То есть, в кейсе у вас нету непосредственно структуры таблиц? Нет >непосредственных связей одной таблицы с другой?
Да есть в минимально необходимом количестве. Ну есть сущность связаная с другими и есть у нее атрибуты не относящиеся к связям. Зачем они в CASE? Чтобы в 2 местах поддерживать?

>ну так я два варианта предложил. Или из кейса разворачивать, или из >некоего скрипта. Как еще?
По-моему совершенно ясно сказали - экспорт-импорт эталонной. Что эталонная это база разработки - это извини ты так придумал про такое никто не говорил.

>Тогда каким образом составляется общий скрипт развертывания базы?
Не составляется. Он не нужен

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

Вообще все выглядит так: есть база разработки и есть база для тестирования и есть продакшн база (причем несколько - логические standby)

Все что есть в тестовой является неким "псевдоэталоном" разработчик не может ничего делать с любым объектом в девелоперской базе если этот объект есть в тестовой базе.

Реализован некий собственный аналог VSS когда чтобы изменить объект в девелоперской базе нужно сначала его пометить в тестовой как модифицируемый. Разработчик "берет" объект (ы) и работает с ними. То чего нет в тестовой базе - является свободным с ним можно делать что угодно. Когда разработчик закончил определенный этам он "коммитит" свои изменения (в том числе указывая какие новые объекты созданные им нужно включить в систему контроля).
После этого изменения (только те которые сказал разработчик - фактически за его подписью) переносятся на тестовый сервер и за них берется отдел тестирования. Если они ничего плохого не нашли - изменения накатываются на продакшн ферму.

>импорт экспорт чего? Не понимаю о чем ты говоришь...
Ну вот того что наделали. Допустим хотим сделать эталонную базу такого-то релиза. Берем проигрываем DDL и получаем базу. На нее накатываем DML - получаем эталон с заполненой системной инфой. Потом делаем экспорт - получаем дамп - отдаем кому надо. Ноу проблем.

← →
bss (2010-10-22 19:53) [44]

Sergey Masloff, очень интересно, начинаю понимать. Есть вопросы:

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

- какими средствами работаете с БД? Например, в Oracle по аккаунту могут зайти много человек, как проверяется что это именно тот разработчик, который пометил объект на модификацию и соответственно ему разрешено это право?

- как я понимаю, отслеживание DDL реализовано на тестовом сервере?

> После этого изменения (только те которые сказал разработчик
> - фактически за его подписью) переносятся на тестовый сервер
> и за них берется отдел тестирования

разработчик выдает DDL-скрипт?

Как вы решаете проблему с неправильными действиями? То есть, разработчик, допустим, решил DROP"нуть таблицу (условный пример), посчитав, что она не нужна. Или в конце концов просто ошибся с именем, скопипастил не туда - всякое бывает. Таблица дропнулась, вылезли косяки.

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

← →
Sergey Masloff (2010-10-22 20:12) [45]

bss (22.10.10 19:53) [44]
>- каким образом запрещается редактирование объектов в девелоперской >базе, которые есть в тестовой базе? Тригеры на схемы, внедрение какой->то своей контрольной системы?
Просто триггер на уровне базы

>- какими средствами работаете с БД? Например, в Oracle по аккаунту >могут зайти много человек, как проверяется что это именно тот >разработчик, который пометил объект на модификацию и соответственно >ему разрешено это право?
аккаунт оракл не при чем. Все девелоперы под одним. Это в рамках рабочей станции делается. То есть берет не просто конкретный разработчик а конкретный разработчик на конкретную рабочую станцию.

>- как я понимаю, отслеживание DDL реализовано на тестовом сервере?
на всех. На самом деле все намного сложнее чем я могу пояснить в коротких постах. Например бывают экстренные ситуации в которых правка осуществляется не на сервере разработки. Это естественно не разработчик делает

>разработчик выдает DDL-скрипт?
Нет. Он в клиенте (не оракловском, наш самописный клиент) помечает что вот эти объекты которые он "брал" он хочет "выложить" (или "отменить взятие"). Также в этом клиенте он помечает новые объекты которые он создал в рамках этой задачи и которые нужны на тестовом сервере. Фактически в списке ему даются все объекты сервера разработки которых нет на сервере тестирования. Он выбирает "свои" но не все а только "не мусорные"

Потом администратор нажимает кнопель в час "X" система бежит по всем объектам помеченым к выкладке определяет что нужно "проиграть" и накатывает.

>DROP"нуть таблицу (условный пример), посчитав, что она не нужна.
Для этого ему нужно "взять" ее с тестового сервера. Если он ее дропнул, ее можно просто "взять" снова. Так что тут еще проще никакой хронологии не нужно.

Дропнуть таблицу на сервере тестирования или боевом не может никто (по крайней мере ни у кого из разработчиков нет туда доступа)

bss (22.10.10 19:53) [44]

Тебе все чтоб трескотня была и умные слова. Проще надо быть :) Обычно вырабатывается набор неких внутрикомандных соглашений, кто что где когда и зачем изменяет, с возможностью отката изменений или отрывания рук. Так как рук жалко, то стараются делать так, чтобы можно было откатить тем или иным способом, а не так, что существует помойка, куда каждый пихает в произвольный момент времени, что ни попадя, а потом испольуется куча навороченных систем, чтобы за этой помойкой следить. Кроме всего прочего, у СУБД достаточно средств, чтобы по ним отследить, когда и кто ее поменял, после этого вопрос "зачем" можно задать конкретному автору изменений. Ну или руки ему оторвать по самую голову.

← →
bss (2010-10-22 22:26) [47]

> То есть берет не просто конкретный разработчик а конкретный
> разработчик на конкретную рабочую станцию.

то есть, разрешение идет на конкретный IP компьютера?
Насчет идентификации разработчика не понял, коли они все сидят под одним акком (у нас также).

> Потом администратор нажимает кнопель в час "X" система бежит
> по всем объектам помеченым к выкладке определяет что нужно
> "проиграть" и накатывает.

ммм... То есть, система бежит по всем помеченным как модифицированные объектам, сверяет с тестовыми объектами и соответствующим образом изменяет структуру в объекте на тестовом сервере?
Определяет какие колонки добавились, какие удалились, как изменились FK, какие появились новые комментарии и так далее?
Навороченная самописная программа получается... А во сколько ты оценил бы время разработки такой системы контроля версий для БД?

> Для этого ему нужно "взять" ее с тестового сервера. Если
> он ее дропнул, ее можно просто "взять" снова

"взять" - это типа как заблокировать в системе контроля версий? Ок... Дальше он делает Drop на девелоперской базе. Дальше делает чекин в СКВ... Реально таблица не дропается на тестовой базе?

И что значит можно снова взять? Если он пытается лочить объект в тестовой базе, а его при этом нет в девелоперской - он пересоздается в девелоперской?

И вообще, я подумал, что если ты залочил существующий в тестовой базе объект, изменил его в девелоперской, потом зачекинил - то изменения в это время и переносятся в тестовую базу?

Сори, опять потерял нить принципа работы...

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

bss (22.10.10 22:26) [47]
>то есть, разрешение идет на конкретный IP компьютера?
>Насчет идентификации разработчика не понял, коли они все сидят под >одним акком (у нас также).
Ну IP или имя станции какая разница. Собственно говоря "checkout" это запись в системной таблице (в другой схеме не относящейся к предметной области). Модификация данных в этой таблице (как и во всех остальных) только персонифицированная. Для этого используется фактически переменная пакета. Установить ее напрямую нельзя а только вызвав функцию в которую передается имя и пароль. Пока функция не выполнилась успешно - переменная неинициирована и системный триггер не дает модифицировать вообще никакие данные. Вобщем все персонифицировано

>То есть, система бежит по всем помеченным как модифицированные >объектам, сверяет с тестовыми объектами и соответствующим образом >изменяет структуру в объекте на тестовом сервере?
Нет сверять ничего не нужно - они изначально одинаковые, просто прогоняются DDL которые делались по этому объекту с момента "взятия"

>"взять" - это типа как заблокировать в системе контроля версий? Ок... >Дальше он делает Drop на девелоперской базе. Дальше делает чекин в >СКВ... Реально таблица не дропается на тестовой базе?
Если сделал CheckIn - дропается. Но тогда обломится тестирование и объект потом восстановится с продакшн базы - на продакшн ничего не дропается пока туча проверок не пройдет. Если дропнется то восстановить все равно можно просто дольше - все же DDL сохранены...

>И вообще, я подумал, что если ты залочил существующий в тестовой базе >объект, изменил его в девелоперской, потом зачекинил - то изменения в >это время и переносятся в тестовую базу?
Ну почти. У нас "CheckIn" это понятие логическое - просто сигнал администратору что на момент очередной "сборки" это должно уйти на тестовую базу. Пока администратор не нажмет кнопку ничего не произойдет - это ж базу в рестриктед нужно переводить и много чего еще...

А так вроде все правильно ты понял ;-)

> bss (22.10.10 18:20) [41]
> > Хотите сказать то, что Вы делаете и то, что получается
> > в принципе не одно и то же?
> не понял вопроса

по-моему достаточно точно сформулировано.
То, что Вы моделируете у себя и то, что получается после внедрения - это не одно и то же? И Вы не можете это никак проверить в автоматическом режиме?

> > друпал твоё всё, там это уже давно решено: и установка,
> > и модификация, и выполнение "долгих" "удалённых" инсталляций.
> это какой-то модуль к какой-то CMS системе как я понял.
> Как это связано с задачей?

"какая-то" cms, "какой-то" модуль, "какой-то" php, "какой-то" unix... ;)

> Или там реализованы какие-то принципы? Можно рассказать
> тогда об этим принципах?

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

← →
bss (2010-10-23 14:12) [50]

> Ну IP или имя станции какая разница. Собственно говоря "checkout"
> это запись в системной таблице

ясно... В принципе, аутентификация по IP - это вариант. Но некоторые БД могут лежать вне локальной сети и чисто технически получится, что доступ от РАЗНЫХ разработчиков с разных компов будет идти с одного IP. Конечно, ситуация не такая уже распространенная. Это один разработчик должен сделать чекаут, а другой в этой БД изменить объект, операция пройдет и запишется на имя первого разработчика...

Также при наличии нескольких серверов интересно, а где хранить собственно журнал DDL операций?

> просто прогоняются DDL которые делались по этому объекту
> с момента "взятия"

а как поступаете с ссылками, например? Child -> Parent table - к какой таблице считается привязанным? Подозреваю, что к Child.
И что делать, если в СКВ я добавил таблицу Child, а Parent не стал добавлять? Тогда возникнет исключение в последовательности DDL операций на тестовой базе... А если учесть, что эти операции не транзакционны - надо лезть в хронологию DDL-операций и что-то ручками править?
В этом и есть проблема, что-то там в прошлом ковыряться в мегабайтах скриптах - утопичное дело...

> Но тогда обломится тестирование и объект потом восстановится
> с продакшн базы

да, восстановится, но каким образом?

Чтобы восстановить DROP"нутую таблицу тебе нужно:

1) создать ее со всеми параметрами типа индексов и прочее.
2) протянуть все существовашие FK
3) наполнить ее данными

Особенно интересен третий пункт. То есть, ты неправильно дропнул таблицу.. В принципе, тебе же нужно просто убрать этот Drop из эталонных DDL-операций и все будет ок. В твоей система значит каким-то образом изменить историю DDL комманд.
А если восстанавливать из продакшна - тебе нужно сделать CREATE и еще возможно на 50 Гб скрипт влива данных, жестоко же...

← →
bss (2010-10-26 23:09) [51]

А кто-нибудь знает готовые системы контроля версий для разработки под БД, в частности, Oracle?

← →
bss (2010-11-14 16:59) [52]

Удалено модератором

Весело тут у вас.
Оарэмщиков скоро реально будут пинать ногами, как гербалайфщиков.

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