> -- Владислав Жаринов писал(а):
> ...И ещё: быть может, чтобы не городить зависимости элементов, надо с самого начала следовать единому подходу к системе?...
Связи между элементами не исчезнут, а вот единый подход в организации управления этими связями, имхо, самое главное. Например, проблемы ER-диаграмм, затронутыездесь, решаются кардинально - отказом от ER-схем (как способ первичного создания структуры БД) и "программированием БД", также как программируется всё остальное в проекте. Когда объектов в БД далеко не одна сотня, они требуют модульного разделения и объединения по логическим связям, которые не всегда выражаются только лишь через "master-foreign key", к тому же прямых технических связей внутри БД может и не быть, и отношения между элементами образуются через прикладное приложение, использующее БД. И до сих пор для программирования БД нет адекватных инструментов. Лично я предпочёл бы удобный текстовый редактор, где бы была реализована поддержка SQL-кода на одних и тех же принципах как и для остального не-SQL кода, например, какздесь(скриншот редактора из проекта Light Table). Для интерактивной работы куда удобнее не наблюдать кучу квадратиков с лесом линий, а, скажем, быстро просмотреть структуру конкретного модуля (обобщённо, в виде списка содержащихся объектов), открыть исходник, например, таблицы (в виде текста DDL-оператора "create table ..."), при необходимости открыть рядом документацию по таблице, связанный исходник "домена" выбранного столбца, тексты операторов "create index ...", список объектов, которые определяет данная таблица (индексы, триггеры и т.д.), список объектов, которые используют данную таблицу (зависимые таблицы, хранимые процедуры) и т.д. и т.п. Общий анализ БД можно выполнять (кроме DB-IDE, а качественных IDE для БД нет) на основе HTML-документации в стиле javadoc и т.п. (например, какpldoc), где все связи, фактически, сведены к табличному представлению. А некоторые, ощущая потребность в системности, пытаются продвинуться дальше, и делают попытки отражать связи не только внутри БД, но и между БД и внешним прикладным кодом, оперирующим СУБД (например, как вHyperSQL).

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

Отсюда:

- важен единый однородный подход;

- упомянутая HTML-документация - это пример реально действующей на практике методики для попытки разобраться в связях между тысячами элементов, где, по своей сути, всё сведено к табличному представлению (с декомпозицией и обобщением). Линии связей там можно встретить разве что в схемах а-ля те же ER-диаграммы (с сомнительной полезностью), которые могут быть сгенерированы для определенного небольшого набора сущностей.