Проектирование универсальной структуры БД Опции

[Tonal]

Не бывает "универсальной структуры БД".
Иначе её бы уже давно разработали и все бы использовали.

Всё очень сильно зависит от класса задач, структуры данных, методов их использования, от типа движка.
"Универсальная" для одного из классов задач будет очень плохо подходить для другого.
Хорошее решение для версионника будет ложить блокировочник и наоборот.

Хотя можно написать некоторое количество шаблонов для сходных задач и приёмов программирования, а потом их использовать в похожих задачах.

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

Сообщение отредактировал Tonal - 2.12.2009, 11:26

[Litkevich Yuriy]

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

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

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

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

[Tonal]

Сходного везде очень много. Но и различий тоже хватает.
Для некоторого круга задач вполне подойдёт просто текстовый файл или файловая система с файликами вместо RDBMS, для некоторых лучше OODB, для каких-то XML-DB...

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

[Elfinit]

может хватит велик изобретать, а стоит посмотреть системные таблицы MS SQL....

Практика показала, что их недостаточно) Да, есть там, например [dbo].[sysobjects] (вроде). Ну и? Там вперемешку таблицы, процедуры, функции?
А как программную логику сделать для создаваемых таблиц? Точнее, чтобы она АВТОМАТИЧЕСКИ генерировалась? Как установить довольно сложные взаимодействия между сущностями? Писать триггеры к системным таблицам? Там получится куча условий и вообще тёмный лес....
В общем, аргумент такой: работа с системными таблицами не универсальна и не гибка.

Для меня является проблемой "Сущность и её свойства" где-то сзади чешется, что свойства тоже являются сущностью, тогда где их держать?

Первое, что пишло на ум - это аналогия reference-type и value-type. Т.е. свойство может быть ссылкой на сущность. А может и has is к сущности.

Вообще, советую почитать про ER-модели, это первое, с чего начинают проектирование БД. В UML можно заглянуть. После этого многое понятно станет. Очевидно, что раз хочется универсальную БД, то надо абстрагироваться от предметной области.

в FireBird

З.Ы. Firebird - реляционная, или объектно-реляционная СУБД? Леньгуглить)

[Litkevich Yuriy]

Firebird - реляционная

такая

[Novak]

А всё же не легче какую-нибудь систему ORM использовать, раз уж очень хочется такой прям объектности с реляционной СУБД?

[Litkevich Yuriy]

систему ORM использовать

я смутно представляю, что это такое

[Iron Bug]

я на заре своей рабочей карьеры разрабатывала крупные базы и по собственному опыту знаю, что всегда хочется спроектировать супер-пупер базу на все случаи жизни, но на деле такая база нафиг не нужна, ибо:
-она будет громоздка, сложна и неудобна в использовании
-она будет тормозить совершенно дико и её нельзя будет использовать для более-менее приличных объёмов данных
-наступит день, когда все её супер-пупер свойства окажутся недостаточны для совершенно очевидного мелкого пустяка и придётся её дорабатывать

кстати, в инете полно чумовых проектов на подобную тему. копай в сторону веб-программирования, там всегда пытаются сделать бэк-офис для создания произвольных документов. у меня даже были ссылки на более-менее удачные решения, но сейчас они канули в лету, ибо я базами уже давно не занималась.
вообще, для таких вещей лучше базу брать с триггерами, пользовательскими функциями и прочей автоматизационной лабудой. это обычно монстры типа Oracle, MS SQL или Sybase. вообще, без таких свойств база как бы и не база, а просто набор файлов данных с интерфейсом.
кстати, как тут выше заметили, служебные таблицы MySQL - отличный пример довольно гибкого решения для многих задач. конечно, не универсальный, но весьма практичный. а с объектами, и тем более программной логикой будете трахаться долго и нудно и мало чего сделаете. всё, что существует в данной области, обычно либо громоздко и неуклюже, либо убого и никому нафиг не нужно на практике.

[Novak]

я смутно представляю, что это такое

По сути это такой сторонний промежуточный слой между тобой и базой данных. В Django таким образом очень удобно работать с моделями - ты описываешь данные, а не то, как они должны храниться.
По сути да, это медленней, менее эффективно. Но при не очень больших объёмах данных вполне оправдано.

Сообщение отредактировал Novak - 3.12.2009, 16:32

[Litkevich Yuriy]

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