powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
25 сообщений из 438, страница 6 из 18
Объектная надстройка над релационной СУБД
    #32842861
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> опасения по поводу нежелательности(непонятно почему?) хранить большие обекты в самой базе

Нет опасений. И нежелательности нет. И речь шла не об объектах, а именно о файлах. Лучший способ хранения файлов - файловая система. По определению.

> а не в файлах, не находят подтверждения.

Хм... цифры и тесты - в студию.

> Все работает отлично, это по факту...Пока правда, только под IB

Еще раз: хранить файлы в базе данных - это ошибка. Хотите ходить по граблям - ходите, лично мне это проблем не создает.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32843392
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32843403
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дык все слышали о граблях, но никто не видел :))

-- Tygra's --
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32844466
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
И хотя тема топика уже давно отошла от того, с чего она начиналась, все-таки хотелось бы немножко к ней вернуться.
Тут уже упоминался стандарт JDO. Правда какого-то ответа я так и не нашел. Поэтому хотел бы задать такой вопрос.

Существует такая группа ODMG, которая и занимается стандартизацией хранения объектов, в т.ч. и отображением их на реляционные БД. Помимо наработок для Java существуют и достаточно четко формализованные принципы и для других языков (например, C++). Как уже было отмечено, существует и большой выбор продуктов O/R мэппинга (Versant Open Access, Solarmetric KODO, ...). Упоминавшиеся в разговоре Object Factory тоже можно связать с реляционными хранилищами (например, FastObjects SQL Object Factory). Разумеется теоретическое обсуждение оптимальных способов проектирования и разработки имеет ценность и само по себе. Но насколько вообще разумно делать продукт, который (насколько я понял) во многом (понял что не во всем) повторяет функциональность давно присутствующих на рынке продуктов известных компаний? Не будет ли более рациональным опираться на существующие в мире наработки с тем, чтобы пойти дальше? Именно в этом случае продукт может привлечь значительный интерес и иметь успех.
ИМХО.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32844548
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Не будет ли более рациональным опираться на существующие в мире наработки с
> тем, чтобы пойти дальше? Именно в этом случае продукт может привлечь
> значительный интерес и иметь успех.

Если говорить о маппинге как таковом - есть не только наработки, но и продакшн решения (hibernate, например). Проблема в том, что imho задача много шире маппинга.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32850682
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..

"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32850836
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vybegallo"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)"Вымывание" это конечно здорово, но только при неграмотном использовании.... конечно если блобы дергаются лишь для того чтоб в гриде их отобразить, то тогда да..
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32851644
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vybegallo Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..

"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)
Хе-хе...Я бы пожалуй с вами и согласился бы, если бы не мой собственный эксперимент! Он не подтверждает вашу теорию. Эксперименты с mssql и opacle впереди, есть у меня ощущение (не могу пока этого доказать), что раскрученные марки Oracle и Mssql в данном конкретном аспекте окажутся позади...
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32851927
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dik76 vybegallo"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)"Вымывание" это конечно здорово, но только при неграмотном использовании.... конечно если блобы дергаются лишь для того чтоб в гриде их отобразить, то тогда да..

Для борьбы с "вымыванием" Информикс придумал хранение и использование блобов отдельно от остальных данных (это, правда, ведет к отдельному геморрою) - но я что-то никак не придумаю, каким образом "грамотное" их использование (не только для "отображения в гридах - это, кстати, тут при чем ?) поможет вам сохранить индексные страницы в буферах. Пример приведете, а то я, может, чего не понимаю в internals ?
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32851937
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Programmer_Ortodox vybegallo Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..

"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)
Хе-хе...Я бы пожалуй с вами и согласился бы, если бы не мой собственный эксперимент! Он не подтверждает вашу теорию. Эксперименты с mssql и opacle впереди, есть у меня ощущение (не могу пока этого доказать), что раскрученные марки Oracle и Mssql в данном конкретном аспекте окажутся позади...

И в чем заключался ваш эпохальный эксперимент, позвольте поинтересоваться ? Вы меряли суммарную производительность сервера ? отмечали изменения hit ratio для чтения и записи до и после использования блобов ?
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32853034
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Programmer_Ortodox funikovyuriТ.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную.

А эту структуру строят изходя из каких знаний/соображений?

На сегодня это пока так:
Подключаемся с sql-серверу, выполняем готовый sql-скрипт. Все, стуктура готова. Для наполнения/реорганизации используется клиентская программа, получается, что это как бы админская утилита. Дальше можно разрабатывать разнообразные приложения, которые при работе с базой пользуются одной и той же структурой, получается такое связующее эти приложения звено. По моему мнению это очень хорошо.

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

Пользователю важен результат. Не важно как, не важно с помощью чего. Ему важен результат. Все-равно как. Пользователью нужно готовое решение.

Разработчику бизнес-правил также не важно как хранятся данные, где хранятся, в каком виде. Ему важны правила обработки данных. Логические связи м/у данными. Разработчику нужна платформа.

Разработчику нужна универсальная платформа. Универсальная насколько это возможно. Созданное Programmer_Ortodox хранилище данных подходит для этих целей. Такое хранилище - нижний слой.
Теперь нужно сделать процедуры добавления/обновления/удаления, истории (версий документов)

Сделать версии процедур. Т.е. историю программ обрабатывающих данные.

История - это отдельный разговор...

И все-таки без описания объектов, их связей (какие объекты куда разрешается вкладывать), их свойств (вязкость можно применить только к жидкостям...) не обойтись. Нужны метаданные.
Возможно эти метаданные будут в виде бизнес-правил.
Надо подумать...

И правильно, что не придерживаешься никакой парадигмы!
Это новое. Такого еще не было. И готового решения нет.

Напиши мне: ICQ 230979104.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32853134
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Нужны метаданные.
> Возможно эти метаданные будут в виде бизнес-правил.
> Надо подумать...

Это бред, вызванный новогодней алкогольной интоксикацией?

> И правильно, что не придерживаешься никакой парадигмы!
> Это новое. Такого еще не было. И готового решения нет.

Готового решения чего? Метаданных в виде бизнес-правил?
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32853154
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Нужны метаданные.
> Возможно эти метаданные будут в виде бизнес-правил.
> Надо подумать...

Это бред, вызванный новогодней алкогольной интоксикацией?

> И правильно, что не придерживаешься никакой парадигмы!
> Это новое. Такого еще не было. И готового решения нет.

Готового решения чего? Метаданных в виде бизнес-правил?

Парирую Ваши нападки молчанием.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32853386
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adisk
Блин! Мужик, верной дорогой идешь! На протяжении многих лет стараюсь сделать то же самое. Давай объединяться!
Вкратце:

Пользователю важен результат. Не важно как, не важно с помощью чего. Ему важен результат. Все-равно как. Пользователью нужно готовое решение.

Разработчику бизнес-правил также не важно как хранятся данные, где хранятся, в каком виде. Ему важны правила обработки данных. Логические связи м/у данными. Разработчику нужна платформа.

Разработчику нужна универсальная платформа. Универсальная насколько это возможно. Созданное Programmer_Ortodox хранилище данных подходит для этих целей. Такое хранилище - нижний слой.
Теперь нужно сделать процедуры добавления/обновления/удаления, истории (версий документов)

Сделать версии процедур. Т.е. историю программ обрабатывающих данные.

История - это отдельный разговор...

И все-таки без описания объектов, их связей (какие объекты куда разрешается вкладывать), их свойств (вязкость можно применить только к жидкостям...) не обойтись. Нужны метаданные.
Возможно эти метаданные будут в виде бизнес-правил.
Надо подумать...

И правильно, что не придерживаешься никакой парадигмы!
Это новое. Такого еще не было. И готового решения нет.



Во! Наконец-то была озвучена основная задача девелопмента!

И вариант решения есть:

Братцы, я с августа месяца активно работаю с Bold for Delphi / Bold for C++.

Совершенно чумовой подход – девелопер разрабатывает объектную модель приложения, на основе ее генерирует базу (Фактически, база данных становится объектной и прозрачной для разработчика.) и строит приложение (обеспечивая автоматизированный переход от модели на UML к функциональному коду). Вплоть до GUI.
Поддерживаются совершенно различные варианты – 1 – 2 – 3 – 4 – 5 – … - звенка.

Поддерживаются самые экзотические связи между данными.
Поддерживается версионность данных (документов).
Поддерживается версионность модели (переход от одной модели к другой).
Поддерживается версионность структуры базы (переход от одной структуры к другой).
Чумовой GUI (контекстно – чувствительный к контексту drag-n-drop, например), полная синхронизация состояния объектного пространства и его визуального представления (никаких датасетов с их рефрешами и проч).
Реализация синхронизации между клиентами системы (например, это можно выразить в возможности совместного редактирования данных с синхронным отображением сделанных удаленными клиентами изменений).
Реализация
Легко создаются новые контролы.
Превосходная поддержка third – party компаниями – технологии, компоненты, расширения…
Реальное разработки проекта сокращается десятикратно.
Дальнейшее развитие – для дот – Net – ECO называется.

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

Поглядите здесь , чтобы не повторяться.


Подводные камни – да, есть. Пару синяков набил. Но уже научился обходить.

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

Но потом!

Посмотрите в сторону Bold, не поздно еще – 2005 год только начался!
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32853619
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перед всеми неоднократно вставала задача:
Нужно описать новый предмет (товар, материал, услугу,...).
Предмет имеет свои, свойственные только ему признаки-атбриуты (свойства).

Как хранить описания предмета?
Добавляем новый справочник!

С добавлением справочника необходимо:
1) сделать форму для ввода данных
2) процедуры проверки правильности вводимых данных
3) форму редактирования
4) форму выбора строки из справочника
5) написать процедуру добавления данных
6) процедуру модификации
7) процедуру удаления
8) процедуры-тригеры проверки целостности данных в базе
9) процедуры для обеспечения истории справочника
10) написать/изменить процедуры для отчетов, где будет нужен справочник
11) изменить/написать сами отчеты
12) Обязательно напишите мне, что еще нужно сделать. Все предложения
будут учтены.

Неоднократно добавляя справочники, документы, создавая процедуры,
формы, отчеты, мы замечаем, что действия однообразны (подобны).
Однообразие и лень подталкивает нашу творческую натуру занятся упрощением
работы. Ее совершенствованием.
Через это проходят все программисты и разработчики БД. Все задумываются
над обобщением данных и над созданием чего-то универсального...

Разные люди справляются по-разному:
1. усидчивые - старательно пишут процедуры, рисуют формы, отчеты.
на это требуется время. аккуратность. увеличивается объем кода и
соответственно процент ошибок.
2. хитрые - копируют куски кода, копируют формы, отчеты. 90% работы
сводится к поиску и замене. все происходит быстро. вроде бы приемлемо
для всех. Человек работает, выполняет работу в срок...
3. смекалистые - (и самые хитрые) накопировавшись вдоволь, обобщают данные,
делают шаблоны для процедур, форм, отчетов. Создают классы. (возможно,
здесь и рождается ООП) Создают генераторы процедур, форм, отчетов.
Все происходит быстро и удовлетворяет всех, но...

Достигнув третей стадии програмеры задумываются: как сделать так, чтобы
ничего не делать? Нельзя ли написать единое хранилище для всех данных?
Создать единые формы ввода? Написать универсальный генератор?

Глядя на файловую систему, понимаем, что единое хранилище возможно.
Кстати, что такое файл?
Это те же данные... Данные с именем. И комбинация ПУТЬ+ИМЯ - это
уникальный код.
Не хватает возможности быстро извлекать данные по разным признакам.
Решается созданием индексов.
Не хватает на файловой системе и самих признаков (атрибутов, свойств,
описывающих данные) Кстати, WinFS, разрабатываемая MicroSoft файловая
система, позволяет добавлять файлам различные атрибуты и искать по атрибутам.

Это не в коем случае не реклама WinFS. MicroSoft как всегда сделает все
очень медленным, требующим Пентиум 10 и Терабайт памяти. За примерами
далеко ходить не надо ;)


Вернемся к нам, к простым смертным.
Дальнейшие пути развития:
Путь 1. Написать единый генератор, использующий метаданные.
Генерировать структуры базы данных, процедуры, формы, отчеты (конечно,
90% отчетов надо будет рисовать ;))
Путь 2. Создать единое хранилище, общие для всех процедуры, формы, отчеты.

Как будем действовать?


adisk
---
PS: Мы все делаем одно дело.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854520
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
ОО надстройка над РБД или Универсальное хранилище данных
(Опираясь на структуру Тенцера)

Для примеров будем использовать небольшой набор данных:
фамилия  имя    отчество    предмет
-------- ------ ----------- -------
Иванов   Иван   Иванович 
Смирнов  Семен  Семенович 
Петров   Петр   Петрович 
                            лопата

Два объекта: 
  человек и предмет.

В привычном для ОО виде:
  Человек
    фамилия
    имя
    отчество
  Предмет
    название

Хранить данные будем в таблице:
DATAS
ID   DATA
---- ---------
1    Иванов
2    Иван
3    Иванович
4    Смирнов
5    Семен
6    Семенович
7    Петров
8    Петр
9    Петрович
10   лопата

Все лежит хорошо, но...
Где фамилия? Где имя? Где предмет?. Непонятно.

Вводим код свойства и таблицу для расшифровки свойств:
PROPERTIES
ID   NAME
---- ---------
1    фамилия
2    имя
3    отчество
4    предмет

Получаем:
DATAS
ID   ID_P DATA
---- ---- ---------
1    1    Иванов
2    2    Иван
3    3    Иванович
4    1    Смирнов
5    2    Семен
6    3    Семенович
7    1    Петров
8    2    Петр
9    3    Петрович
10   4    лопата

Имеем данные и можем понять, что это за данные.
Как отсюда выяснить кто есть кто? Иванов Иван, Иванов Семен, 
Иванов Петр – как правильно? Непонятно.
Для связывания данных введем код экземпляра.
По аналогии с простой таблицей, код экземпляра (ID_S)– это номер
строки. Код свойства (ID_P) – это поле.

Получаем:
DATAS
ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
2    1    2    Иван
3    1    3    Иванович
4    2    1    Смирнов
5    2    2    Семен
6    2    3    Семенович
7    3    1    Петров
8    3    2    Петр
9    3    3    Петрович
10   4    4    лопата


В привычном понимании таблица выглядела бы так:

  | 1(фамилия)  2(имя)  3(отчество) 4(предмет)
--|-----------  ------  ----------- -------
1 | Иванов      Иван    Иванович 
2 | Смирнов     Семен   Семенович 
3 | Петров      Петр    Петрович 
4 |                                 лопата

Следует отметить, что в универсальной таблице данные 
хранятся “как есть”, то есть поле DATA не имеет типа!
В этом заключается сложность построения универсальной модели
в существующих реляционных БД.
Можно данные хранить в строковом поле (varchar) или в 
универсальном (BLOB), но перед операциями над полями (SUM, 
конкатенация строк,...) необходимо будет преобразовать данные.
Нужно универсальное поле. 
Может кто знает такое?

...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854527
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
В данная структуре можно хранить «перечисления»!
DATAS
ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
12   1    1    Ивановский

Две фамилии у одного человека одновременно!
С фамилиями, конечно, казус, но пример показывает возможность
хранения «перечислений».


Как узнать, кому принадлежит лопата?
В реляционной базе понадобится добавить поле – код родителя.
Что если лопата принадлежит двум людям?
(связь многие ко многим)
Добавляем таблицу с двумя полями: код родителя и 
код предмета. (более универсальный способ)
В нашей базе для описания связей между данными добавим таблицу 
(LINKS). В LINKS два поля: код родителя и код предмета.
Логически связь можно описать как: Иванов владеет лопатой,
или, если прочитать наоборот: лопата принадлежит Иванову.
Получаем:
LINKS
ID_1  ID_2
----  ----
1     4


История.
Легко реализуется добавлением двух дат:
дата начала и дата окончания.
Получаем период достоверности информации

Получаем:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

Лопата была «лопатой» в 2004 году и стала совком с 2005-го года.
Чтобы не производить каждый раз фильтрацию по дате, вынесем 
текущие (достоверные на сегодняшний день) данные в отдельную таблицу.
Будем хранить ВСЕ данные в архиве (одной большой таблице
DATAS_A) и текущие данные в отдельной таблице (DATAS).
Другими словами: таблица DATAS будет видом (view)
таблицы DATAS_A.
Или по-другому: таблица DATAS – это данные из DATAS_A
отфильтрованные по дате.

Получаем:
архив:
DATAS_A
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

актуальные данные:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/05          совок

связи:
LINKS
ID_1  ID_2  DATEON   DATEOFF  
----  ----  -------  -------  
1     4     01/01/05 

Запись в LINKS показывает, что «Иванов» владеет «лопатой» 
с 01/01/05.
Также можно сделать историю для свойств и получить историю БАЗЫ!

...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854528
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
В данная структуре можно хранить «перечисления»!
DATAS
ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
12   1    1    Ивановский

Две фамилии у одного человека одновременно!
С фамилиями, конечно, казус, но пример показывает возможность
хранения «перечислений».


Как узнать, кому принадлежит лопата?
В реляционной базе понадобится добавить поле – код родителя.
Что если лопата принадлежит двум людям?
(связь многие ко многим)
Добавляем таблицу с двумя полями: код родителя и 
код предмета. (более универсальный способ)
В нашей базе для описания связей между данными добавим таблицу 
(LINKS). В LINKS два поля: код родителя и код предмета.
Логически связь можно описать как: Иванов владеет лопатой,
или, если прочитать наоборот: лопата принадлежит Иванову.
Получаем:
LINKS
ID_1  ID_2
----  ----
1     4


История.
Легко реализуется добавлением двух дат:
дата начала и дата окончания.
Получаем период достоверности информации

Получаем:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

Лопата была «лопатой» в 2004 году и стала совком с 2005-го года.
Чтобы не производить каждый раз фильтрацию по дате, вынесем 
текущие (достоверные на сегодняшний день) данные в отдельную таблицу.
Будем хранить ВСЕ данные в архиве (одной большой таблице
DATAS_A) и текущие данные в отдельной таблице (DATAS).
Другими словами: таблица DATAS будет видом (view)
таблицы DATAS_A.
Или по-другому: таблица DATAS – это данные из DATAS_A
отфильтрованные по дате.

Получаем:
архив:
DATAS_A
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

актуальные данные:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/05          совок

связи:
LINKS
ID_1  ID_2  DATEON   DATEOFF  
----  ----  -------  -------  
1     4     01/01/05 

Запись в LINKS показывает, что «Иванов» владеет «лопатой» 
с 01/01/05.
Также можно сделать историю для свойств и получить историю БАЗЫ!

...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854534
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
Как получить список людей? 

Или другими словами: 
Как выбрать все объекты со свойствами: фамилия, имя, отчество?
При этом нужно учитывать, что фамилия, имя или отчество может отсутствовать.

Сначала выберем записи с интересующими данными (фамилиями, именами, отчествами):
SELECT id_s
 FROM datas
 WHERE id_p = 1 OR id_p = 2 OR id_p = 3
 GROUP BY id_s
 INTO TABLE tmp

затем сами данные:
SELECT
 datas.id_s,
 datas.id_p,
 datas.data
 FROM datas, tmp
 WHERE 
  datas.id_s = tmp.id_s AND
  (datas.id_p = 1 OR
  datas.id_p = 2 OR
  datas.id_p = 3)
 ORDER BY id_s, id_p
 INTO TABLE people

что откуда:
1 – для фамилии
2 – для имени
3 – для отчества
напомню:
id_s – код экземпляра (код строки)
id_p – код свойства (код поля)

Результат:
people
ID_S ID_P DATA
---- ---- ---------
1    1    Иванов
1    2    Иван
1    3    Иванович
2    1    Смирнов
2    2    Семен
2    3    Семенович
3    1    Петров
3    2    Петр
3    3    Петрович

Нужные данные получены.

...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854588
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
Группировки.
Подсчет суммы с группировкой.
Будем считать сумму с группировкой по фамилии.

DATAS
ID_S ID_P DATA
---- ---- ---------
1    1    Иванов
2    1    Смирнов
3    1    Петров
1    5    100
1    5    1000
2    5    100
3    5    100

То есть аналогичная таблица будет выглядеть так:

  | 1(фамилия) 5(сумма)
--|----------- --------
1 | Иванов     100
1 |            1000
2 | Смирнов    100
3 | Петров     100

После группировки должны получить:

  | 1(фамилия) 5(сумма)
--|----------- --------
1 | Иванов     1100
2 | Смирнов    100
3 | Петров     100

или по-новому:
NEW
ID_S ID_P DATA
---- ---- ---------
1    1    Иванов
2    1    Смирнов
3    1    Петров
1    5    1100
2    5    100
3    5    100

То есть задача сводится к группировке данных по...
коду экземпляра!

SELECT
 id_s ,;
 SUM(data) as sum
FROM datas
GROUP BY id_s
WHERE id_p = 5
INTO TABLE grouped

grouped 
ID_S SUM
---- ---------
1    1100
2    100
3    100

...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854615
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О хранении файлов в БД:
Можно хранить. Бесспорно.
Только как быть с большими файлами, с музыкой, с фильмами?
Возьмем для примера фильм.
Получается надо выкачать из базы файл размеров 650 М, куда-то его сохранить...

Или же делать из базы файловую систему с возможностью передвижения по данным (fseek()). База в свою очередь будет работать с файловой системой, где будет выполнять опять же fseek()...
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854701
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
To adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854717
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VybegalloTo adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Что ж.
Возможно еще не дорос.
Прекрасно осознаю, что будет падение производительности.
Будет ли оно столь ощутимым? Думаю нет.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854845
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
adisk VybegalloTo adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Что ж.
Возможно еще не дорос.
Прекрасно осознаю, что будет падение производительности.
Будет ли оно столь ощутимым? Думаю нет.

Ну давайте я помогу дорасти.
Дано :
таблица customers, 100 000 записей
customer_id int
customer_desc char(50)

Таблица orders, 1 000 000 записей
order_id int
customer_id int
order_desc char(50)
order_cost decimal (9,2)
order_date date
order_flag char(1)

Требуется :
найти сумму отгруженных договоров (order_flag="Y") с 1.1.2004 по 31.12.04 по каждому покупателю и описание покупателя.

select customer_id, customer_desc , sum(order_cost) from customers, orders
where customers.customer_id = orders.customer_id
and order_flag = "Y"
and order_date between "01/01/2004" and "12/31/2004"
group by 1, 2


Давайте вашу модернизированную схему и запрос, время выполнения я сейчас померяю для своей задачи и потом на том же железе - для вашего варианта.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32854847
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня есть четкое убеждение, что вышеописанная идея "универсального хранилища" подходит только для создания справочников номенклатурных позиций, так как там довольно мало реальных записей (под этой цифрой я подразумеваю 50000-60000).
Если при этом учесть, что в "универсальном хранилище" записей, описывающих каждую позицию, будет порядка в 5 раз больше, то с производительностью системы, в которой все так реализовано, будет все понятно.

Городить бизнес-логику в такой системе я думаю, не есть удобно, а довольно тяжело. Надо ведь реализовать такие вещи, как ссылочную целостность, уникальность и др. Говорю я, что тяжело, так как сам создавал такую систему.Она поддерживала и целостность и уникальность (как по простым поля, так и по составным) и прочее, но именно из-за своей производительности "база данных в базе данных" смысл имеет очень малый. Опять таки, можно же добавлять данные непосредственно в таблицы словаря БД (чур меня) и будет та же "универсальность" ... -:)

Кстати, в инете полно таких "универсальных хранилищ". Если надо, то когда выйду на работу, моги кинуть ссылки.
...
Рейтинг: 0 / 0
25 сообщений из 438, страница 6 из 18
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]