crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Проектирование универсальной структуры БД
Введите ваше имя
Подтвердите код

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

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Sokoloff Дата 4.12.2009, 12:54
 
Цитата(Novak @ 4.12.2009, 11:48) *
А смысл создавать новый язык, если уже есть готовые, нужно только реализовать тот самый мэпинг... систему соотношения, во)


Сразу оговорюсь, я не являюсь профессионалом в данной области.

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

То на что я глядел из ORM (глядел, не работал, сейчас даже названий не вспомню) реализовывали немного другой подход. В процессе проектирования описывались структуры данных, потом запускался скрипт создания базы для необходимых объектов. Юрию нужно добавление новых атрибутов в рантайме. Если есть готовые ORM реализующие это, подскажите Юрию, скорее всего для C++.

Как-то все остановились на "для каждого типа данных использовать отдельную таблицу", я предложил свои 5 коп.
Novak Дата 4.12.2009, 11:48
  А смысл создавать новый язык, если уже есть готовые, нужно только реализовать тот самый мэпинг... систему соотношения, во)
Sokoloff Дата 4.12.2009, 1:41
  Как уже сказали это будет медленнее чем база написанная под конкретную задачу.
На мой взгляд, это похоже на создание нового языка программирования. Я бы шел снизу вверх, и мне это видится примерно так:

Базовые типы.
Строка, целое, десятичное, дата, время и.т.д. Представлены таблицами вида [ID, Value].

Ссылки (указатели)
Каждая таблица имеет свой TableID. Ссылка это пара TableID и ID записи в соответствующей таблице. Ссылка может ссылаться на все типы, включая массивы и объекты.
Если нужны ссылки на ссылки, то к базовым классам добавляем таблицу ссылок вида [ID, RefTableID, RefID] .

Массивы
В таблице массивов хранятся не значения, а ссылки на значения, поэтому в массиве можно хранить элементы разных типов. Вид таблицы: [ID, ArrayID, Index, RefTableID, RefID]. ArrayId - поле по которому можно отделить элементы одного массива от другого.

Объекты или коллекции
Наборы именованных ссылок, вид [ID, ObjectID, Key, RefTableID, RefID] . В твоем случае конденсаторы и резисторы представляются именно ими. Ссылка может ссылаться на что угодно даже на другой объект, т.е. мы можем хранить деревья, строить списки и.т.п.

Классы
Если хотим иметь более строгие объекты, то создаем еще таблицу в которой перечислены поля объектов, их типы и опции полей. Что-то типа [ID, ObjectID, FieldType(храниться TableID), Required ...].


Работать напрямую с таблицами нельзя, нужно писать хранимки. Для поддержания целостности, нужны триггеры.


IMHO получается довольно универсальная и расширяемая система, но по поводу скорости работы вопрос.
Это не готовый проект, а только мои размышления.
Litkevich Yuriy Дата 3.12.2009, 16:59
  вот если взять системы сбора и обработки данных, то там мало что меняется по своей сути, меняются пожалуй только названия объектов и их свойств. Если ограничится такой областью применения, то наверно можно получить и резвую систему.
Novak Дата 3.12.2009, 16:32
 
Цитата(Litkevich Yuriy @ 3.12.2009, 15:26) *
я смутно представляю, что это такое

По сути это такой сторонний промежуточный слой между тобой и базой данных. В Django таким образом очень удобно работать с моделями - ты описываешь данные, а не то, как они должны храниться.
По сути да, это медленней, менее эффективно. Но при не очень больших объёмах данных вполне оправдано.
Iron Bug Дата 3.12.2009, 15:32
  я на заре своей рабочей карьеры разрабатывала крупные базы и по собственному опыту знаю, что всегда хочется спроектировать супер-пупер базу на все случаи жизни, но на деле такая база нафиг не нужна, ибо:
-она будет громоздка, сложна и неудобна в использовании
-она будет тормозить совершенно дико и её нельзя будет использовать для более-менее приличных объёмов данных
-наступит день, когда все её супер-пупер свойства окажутся недостаточны для совершенно очевидного мелкого пустяка и придётся её дорабатывать :)

кстати, в инете полно чумовых проектов на подобную тему. копай в сторону веб-программирования, там всегда пытаются сделать бэк-офис для создания произвольных документов. у меня даже были ссылки на более-менее удачные решения, но сейчас они канули в лету, ибо я базами уже давно не занималась.
вообще, для таких вещей лучше базу брать с триггерами, пользовательскими функциями и прочей автоматизационной лабудой. это обычно монстры типа Oracle, MS SQL или Sybase. вообще, без таких свойств база как бы и не база, а просто набор файлов данных с интерфейсом.
кстати, как тут выше заметили, служебные таблицы MySQL - отличный пример довольно гибкого решения для многих задач. конечно, не универсальный, но весьма практичный. а с объектами, и тем более программной логикой будете трахаться долго и нудно и мало чего сделаете. всё, что существует в данной области, обычно либо громоздко и неуклюже, либо убого и никому нафиг не нужно на практике.
Litkevich Yuriy Дата 3.12.2009, 15:26
 
Цитата(Novak @ 3.12.2009, 16:35) *
систему ORM использовать
я смутно представляю, что это такое
Novak Дата 3.12.2009, 13:35
  А всё же не легче какую-нибудь систему ORM использовать, раз уж очень хочется такой прям объектности с реляционной СУБД?
Litkevich Yuriy Дата 2.12.2009, 20:44
 
Цитата(Elfinit @ 2.12.2009, 22:58) *
Firebird - реляционная
такая
Elfinit Дата 2.12.2009, 19:58
 
Цитата(trdm @ 2.12.2009, 1:43) *
может хватит велик изобретать, а стоит посмотреть системные таблицы MS SQL....

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


Цитата(Litkevich Yuriy @ 1.12.2009, 21:52) *
Для меня является проблемой "Сущность и её свойства" где-то сзади чешется, что свойства тоже являются сущностью, тогда где их держать?

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

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

Цитата(Litkevich Yuriy @ 1.12.2009, 21:52) *
в FireBird

З.Ы. Firebird - реляционная, или объектно-реляционная СУБД? Леньгуглить)
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.3.2024, 0:35