MasterZiv
belugin пишет:

> В работающей БД DDL-я быть не должно
> Почему?

Транзакционный DDL - очень сложная и эксклюзивная
операция. Её нельзя давать пользователям в руки.

А ее и не надо им давать в руки. В руки они получают инструмент, который полностью контролирует их действия и работает в рамках требований к системе, предъявляя в том числе и свои требования к знаниям и квалификации пользователей, которые будут пользоваться таким инструментом. Здесь стоит только вопрос обоснованности такого инструмента и требования изменения структуры/логики в БД конечным пользователем продукта (естественно имеется ввиду ИТ специалист клиента, а не конечный лузер). В 99% случаев такая динамика используется разработчиками не по назначению - с мифической целью сделать супер пупер платформу, на которой конечный пользователь сам сможет рисовать себе нужные программы. 1% случаев - это или ERP или специфика пользователя. В таких случаях, если в основном требуется хранения данных без сложной обработки (тот же интернет магазин, складской учет и т.д.), EAV хорошее решение. Если требуется не только хранить изменяющиеся структуры данных, но и производить ряд операций над большими массивами данных (статистика, аналитика, автоматизированные расчеты и т.д.), то EAV будет плохим средством, ибо на выходе получим сложные запросы и тормоза, здесь уместнее закладываться на DDL для тех классов сущностей, у которых может изменяться структура.

MasterZiv
ASCRUS пишет:

> А ее и не надо им давать в руки. В руки они получают инструмент, который
> полностью контролирует их действия и работает в рамках требований к
> системе, предъявляя в том числе и свои требования к знаниям и

Без базару. Но этот инструмент всё равно таки в конечном итоге
ВЫПОЛНИТ этот самый DDL и заблокирует БД эксклюзивно.

Не, конечно же не так всё страшно, заблокирует он на только
каки-то 2-3 минуты, но вот ежели в таблице 5-10 миллионов,
то уже будет минут 10-20. Ну и т.д.

Ну так в том то и дело, что это уже не вопрос программиста, а архитектора и аналитика. Вопрос этот должен быть поставлен и решен в ТЗ - частота и условия проведения изменения метамодели системы. В моем текущем проекте это выведено на администратора - он производит изменения метамодели и самостоятельно запускает режим синхронизации, который проводит изменение физической модели БД, перестраивает формы просмотра и изменения информации. Здесь это оставлено на усмотрение человеческого фактора, так как проект не критичный - кол-во пользователей не большое, массив информации большой, но изменения метамодели не частые. В другом же проекте сейчас разрабатывается более сложная схема, так как там планируемый ежедневный прирост информации около 4 гб и кол-во пользователей за тысячу. Здесь изменения будут происходить в многофазовом режиме: изменение метамодели->проведение синхронизации на тестовой БД->проведение тестирования->синхронизация боевой базы с остановкой на профилактические работы (на ночь). Причем здесь же еще сразу обговариваются условия, когда вне зависимости от видимости и доступности БД, работы сетевых каналов и т.д., существуют группы пользователей, которым необходимо в установленное время обеспечить продолжение их работы по вводу информации. Все это вкупе называется технологическим процессом и именно он должен определять, как, когда и насколько можно изменять структуру базы и кто может подождать, а кто должен работать дальше. Ну а если просто без привязки к конкретным условиям, что DDL зло, так как он блокирует таблицы ... то да, он зло ;)

Кстати в догонку - в зависимости от условий проекта, DDL может и не оказывать значительных временных задержек - например в моих проектах у существующих сущностей могут добавляться новые столбцы и изменяться размер длины и разрядности поля. Смены типов или имен полей не предусмотрено. Все поля в таблице объявляются как NULL, а требование NOT NULL обрабатывается в триггере представления, через которое и работают клиентские приложения (слой таблиц для клиентов не доступен).

guest_20040621> изменение метамодели->проведение синхронизации на тестовой БД->проведение
> тестирования->синхронизация

Дружище, какая метамодель? Чтобы метамодель менялась, сначало нужно реализовать метаметамодель, а это явно не для Вас задача. Может, таки _модель_ меняется?

Удивляюсь, как с такой кашей в голове вообще можно проектированием заниматься.
Модель в БД, метамодель сверху в своих таблицах, а каша у Вас в голове.

Foxluck Типа создать случайным образом 1000 таблиц. Набить данными. По играть с alter table Случайные выборки сделать.
Смысл ? У Вас в задаче пользователи будут случайным образом создавать 1000 таблиц, добавлять или изменять просто так в них колонки ? :)

guest_20040621> Модель в БД, метамодель сверху в своих таблицах, а каша у Вас в голове.

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

MasterZiv
Ты думаешь, программист - это тот, кто в редакторе notepad
пишет код на visual basic ? Я на этот счёт непного другого
мнения.
...

Ладно, фиг с ней, с задержкой. А как ты решаешь проблему с количеством
атрибутов ? Я хочу 1000. Нет, завтра уже -- 2000. А потом - 3000.

Вот я о том и говорю. Когда программист начинает хотеть неизведанные дали, в итоге получается супер пупер универсальная платформа. Когда же есть некая нестандартная задача, не вписывающаяся к примеру в рамки РСУБД (требования динамического изменения структуры в рантайме), архитектор не начинает проводить тесты на таблицах с тысячами колонок, миллиардами записей и прочим, а для начала полностью собирает по задаче все требования и ограничения, стараясь максимально ограничить круг нестандартности, ибо как известно клиенты часто на словах хотят больше, чем им нужно на самом деле. И только после этого выбирается решение, в том числе на определенной РСУБД проводятся тесты с целью выявления подводных камней в решении. В моем случае в обоих проектах поставлено ограничение на кол-во столбцов в 255. Тоже самое касается и максимального кол-ва записей в актуальных и исторических таблицах - определен собираемый объем данных, правила и время их хранения в операционной и аналитических базах, где OLTP и DSS - это разные СУБД, ибо предназначены для выполнения разных задач.

Еще раз подчеркиваю - при выборе решения надо руководствоваться не тем, что лучше - DDL vs EAV vs Еще чего то, а отталкиваться от конкретной задачи и поставленных условий. Если соблюдать это правило, то в тему будет и DDL и EAV и Еще чего то, потому что когда есть определенные задачи и условия - то решение будет простым, эффективным и цели будут достигнуты. Когда есть мифическая цель сделать нечто универсальное, то процесс разработки будет бесконечным, а проект считаться безнадежным.

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