Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9 10 11   вперед  Ctrl      все
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
У М3 420 л.с., какие могут быть помехи ?
6 июн 13, 15:52    [14400599]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11485
PSV100
Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.
В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.
6 июн 13, 21:28    [14402290]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Мурыч
Member

Откуда:
Сообщений: 142
Basil A. Sidorov
PSV100
Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.
В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.


Почему Вы подумали что это ORM?
6 июн 13, 22:12    [14402476]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина
...Например, М0 - это ER-модель. Даже Дейт не считает ее не формальной.
?
Введение... (8-изд) стр 532
"Следует отметить, что семантическое моделирование имеет также несколько других названий, например, моделирование данных, ER-моделирование, моделирование сущностей и объектное моделирование. В настоящей книге по указанным ниже причинам предпочтение отдано термину семантическое моделирование (которое иногда называют также концептуальным моделированием).
Термин моделирование данных не подходит, поскольку он конфликтует со сложившимся ранее определением термина модель данных, который обозначает формальную систему наподобие реляционной модели..."
Бредятина
С каких пор под реляционной понимается система, в которой нет хранимых отношений? А есть только временные отношения, как результаты запросов???

стр 126
1) "Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных (т.е. переменных отношения — relvar), значениями которых являются отношения". И все. Где то рядом идут рассуждения о базовых и производных переменных отношений, но нигде нет формального требования, что без базовых переменных не обойтись.
2) У меня хранимые отношения есть. Все значения атрибутов объектов (я называю из компонентами объектов) - это, по Дейту, "типы, допускающие реляционное присваивание". Как только я реализую компоенент как хранимый, можно смело говорить о существовании хранимых отношений, значения которого как-то характеризует отдельные экземпляры какой-то сущности объекты какого-то класса. Причем это происходит в той проекции, где я описываю предметную область (эта проекция не является реляционной).А дальше система, пользуясь свойствами реляционной модели, собирает эти значение в большие отношения, которые как то характеризуют множества экземпляров.
Бредятина
А как же нормализация, например (под которой часто понимают именно реляционную нормализацию)? И проектирование БД в целом?

Про проектирование было здесь 14390609. А нормализация не есть вопрос формализма. Даже в первой НФ отношения есть отношения.
7 июн 13, 01:27    [14403214]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина
Просмотрев презентацию еще раз, я пришел к выводу, что Вы используете модель _мод, М5, основанную на гипотезе, что [Мир состоит (только) из сущностей, обладающих свойствами].
Я в десятый раз повторяю, что из средств описания предметной области в прототипе (и в презентации) реализованы только классы. Поэтому Вы и видите М5. Таблиц в презентации нет( а для меня они очевидны). Были бы таблицы, Вы еще что-нибудь увидели.
Бредятина
...SELECT * FROM Студент...
Про звездочки, применительно к классам,я думаю. Это КМК, не является ни вопросм М, ни формальным вопросом; чисто языковая вещь,хотя и привычная.

В любом случае
Бредятина
...если "Изучает" является значением некого атрибута результирующего...
меня поразило. "Изучает" - это имя в схеме данных. Оно в запросе может появиться, и, соответственно, в заголовках результат запроса.
7 июн 13, 01:39    [14403239]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
PSV100
Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.
В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.


1) Вот из-за таких вопросов я и отказываюсь лезть на концептуальный уровень. Взамен я предлагаю систему, где есть и классы и таблицы, и которую каждый может использовать как хочет. Не нравятся классы - пользуйтесь только таблицами. А кому-то только классы нравятся. Ну а кто-нибудь захочет изобразить комбинированную схему.
2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности. А я думаю, что нормализация, как все остальное, что проходит в рамках реляционной модели, к этим непонятным и неопределенным сущностям (и др. концептуальным вещам) отношения вообще не имеет. Не бывает отдельно строк накладной и заголовка. И, нормализовав данные накладной, можно продолжать думать о ней, как о едином целом. А в RxO вы можете эту мысль реализовать.
3) Опять ORM. Я даже пример 14390674 дал, что бы показать что RxO - это не ORM, что в RxO классы рядом и вместе с таблицами, что это одна система, а не попытка насильно поженить две разные. Вот, теперь человека перепугали.:)
7 июн 13, 02:12    [14403297]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
Basil A. Sidorov
В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.

И в чём же именно концептуальная ошибка? Есть реляционная модель, есть ООП, у каждой стороны свои свойства исходя из их сути, и задача ORM их состыковать. Но это не концептуальная ошибка именно ORM, это такова цель. Другое дело, что, в целом, процесс проектирования, моделирования и т.д. заложил такую форму применения соответствующих технологий, где могут быть проблемы (в прочем, как и везде).

Здесь коллега Бредятина давал ссылку на своё понимание сути ORM, т.е. если "модель данных должна быть одна и та же на концептуальном и логическом уровнях" - то и нет потребности в ORM и подобных увязках.
7 июн 13, 03:18    [14403349]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
U-gene,

Всё таки, хотелось бы понять сущность более низкого уровня, чем классы.

Сделаю предположение, что на нижнем уровне лежит "чистая" РМД, полная "sql-трансформация" в лоб. Условно, пусть те же классы "Накладные" и "Товары" трансформируются в соответствующие таблицы sql-сервера "Шапки накладных", "Их строки", "Товары". Проблемы отчасти связаны с тем же "несимметричным доступом", о котором опять же говорил коллега Бредятина. Если коротко, то реальная практика применения реляционных СУБД часто вынуждает в тех же строках накладных держать реквизиты "дата документа", "код поставщика" и т.п., т.е. дублировать некоторые поля из "шапки" накладной. Таким образом достигается возможность уменьшить потребность в обращении к "шапкам", когда над "строками" документов выполняются массовые операции (расчёт типовых агрегатных оборотов, расчёт цен и т.п.), т.е. в запросах не будет соединения с "шапками", что уменьшает нагрузку и т.д. Плата за это - дублирование данных, больше дискового пространства, лишние индексы. Но, в целом, "по отрасли" это терпимая плата, и вот уже много лет реляционные СУБД относительно успешно применяют, и считают их универсальными.
Негативный момент - якобы нарушается идеологическая гармония РМД, т.е. в реальной практике добиться идеальной нормализации затруднительно.

В этом случае, проблема в RxO, фактически, переносится автоматом. Поскольку через классы задают некую прикладную модель, при этом же она выражает и как бы конечную модель (логическую) в БД, то часто классы "накладных" на самом деле вынужденны будут задавать как-то так:
CREATE CLASS Накладная
( 	Номер      STRING,
	Дата  	   DATETIME,
	Поставщик  INTEGER,
	...
	Содержимое SET OF
	( 	
		Дата  	   DATETIME,
		Поставщик  INTEGER,
		Товар      INTEGER,
		...
	)
);

т.е. с дублированием полей в "строках" из "шапки". Нарушается идеологическая чистота прикладного моделирования.

Сейчас я подозреваю, что в прототипе сегодня на нижнем уровне работает некая прикладная система (пусть будет а-ля EAV, не важно), к тому же вряд ли реализована полная трансформация в SQL, скорее всего, работает и свой интерпретатор. Но прототип есть прототип, пока идёт обкатка концепций и т.д. Но, если и в финальном продукте система будет реализована поверх "EAV", то разработчикам в любом случае нужно понимать всю логику до конца, и управлять всеми нюансами. Если будет полная трансформация в "чистою" РМД, то получим проблемы, указанные выше. Если в иную РМД-форму, то тоже необходимо понимать как.

Т.е. если проектировать, моделировать, программировать в условиях полной абстракции уровней, в полном игноре "соседей", то можем в итоге и получить "игнор".

Вы оценивали подобные проблемы, не приведёт ли это к тому, что часто будут вынуждены использовать Ваши планируемые таблицы, вместо классов?
7 июн 13, 03:26    [14403356]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
PSV100
"модель данных должна быть одна и та же на концептуальном и логическом уровнях" - то и нет потребности .....

То и нет потребности в разных уровнях: раз модель одна и та же, то они (уровни) ни чем и не отличаются.

Наверное, на самом деле имелось в виду не одна и та же модель, а один и тот же тип модели. Напрмер, ООМД на всех уровнях, тогда как для РМД на концтуальном уровне ER. Естественно, в первоисточниках речь о недостатке, а не об обязательности.

Но не очевидно, что это и недостаток во всех отношениях.
Специализированные в своих областях (в данном случае уровнях), часто лучше комбайна в этих областях.
В UML мы же с удовольствием юзаем разные диаграммы.
7 июн 13, 08:25    [14403561]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Введение... (8-изд) стр 532
"Следует отметить, что семантическое моделирование имеет также несколько других названий, например, моделирование данных, ER-моделирование, моделирование сущностей и объектное моделирование. В настоящей книге по указанным ниже причинам предпочтение отдано термину семантическое моделирование (которое иногда называют также концептуальным моделированием).
Термин моделирование данных не подходит, поскольку он конфликтует со сложившимся ранее определением термина модель данных, который обозначает формальную систему наподобие реляционной модели..."

И снова обращаю Ваше внимание на недопустимость столь поверхностного отношения))
Я детально изучаю Ваши труды, а Вы даже к Дейту относитесь пренебрежительно:
"Но при более внимательном чтении работы [14.6] можно предположить, что ER-модель действительно является моделью данных, но такой, которая представляет собой лишь небольшое дополнение к реляционной модели...".
А как же! Конечно, небольшое. Но достаточное для необходимости в архитектуре "модель верхнего уровня+маппинг+РМД". Но к Вашей системе это не относится, так как ни РМД (для перманентных данных см. далее), ни маппинга у Вас нет. Вы, в отличие от ViPRos, не поленились (он аргументировал использование такой архитектуры желанием использовать готовую инфраструктуру на уровне хранения и обработки данных).
U-gene
стр 126
1) "Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных (т.е. переменных отношения — relvar), значениями которых являются отношения". И все. Где то рядом идут рассуждения о базовых и производных переменных отношений, но нигде нет формального требования, что без базовых переменных не обойтись.

Очень плохо. Опять(((
Стр. 51 - относится к ЛЮБОЙ БД, хоть реляционной, хоть не реляционной:
"... данные в базе являются перманентными, поскольку после того, как они были приняты средствами СУБД для помещения в базу, их последующее удаление возможно лишь при использовании соответствующего явного запроса к базе данных, но не в результате какого-либо побочного эффекта от выполнения некоторой программы...
База данных - это некоторый набор перманентных (постоянно хранимых) данных..."
U-gene
2) У меня хранимые отношения есть. Все значения атрибутов объектов (я называю из компонентами объектов) - это, по Дейту, "типы, допускающие реляционное присваивание". Как только я реализую компоенент как хранимый, можно смело говорить о существовании хранимых отношений, значения которого как-то характеризует отдельные экземпляры какой-то сущности объекты какого-то класса. Причем это происходит в той проекции, где я описываю предметную область (эта проекция не является реляционной). А дальше система, пользуясь свойствами реляционной модели, собирает эти значение в большие отношения, которые как то характеризуют множества экземпляров.

Буду вот так вытягивать информацию и дальше, чтобы разобраться наконец-то какая у Вас архитектура - с маппингом и РМД или нет:)
U-gene
Про проектирование было здесь 14390609. А нормализация не есть вопрос формализма. Даже в первой НФ отношения есть отношения.

Что было про проектирование??? Обоснование, что проектирование БД осуществляется без МД?
7 июн 13, 13:47    [14406124]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Я в десятый раз повторяю, что из средств описания предметной области в прототипе (и в презентации) реализованы только классы. Поэтому Вы и видите М5. Таблиц в презентации нет( а для меня они очевидны). Были бы таблицы, Вы еще что-нибудь увидели.

Не корректно. И не честно. Давайте без "если бы". Я очень четко написал, что вместо термина "Тип сущности" Вы используете термин "Класс". Пожалуйста, дайте замечанию по существу по рассмотренному мной примеру. Я же большую работу вместо Вас провожу, чтобы сделать понятными Ваши разработки...
U-gene
Про звездочки, применительно к классам,я думаю. Это КМК, не является ни вопросм М, ни формальным вопросом; чисто языковая вещь,хотя и привычная.

Прокомментируйте по существу. Звездочка не влияет на существо, надеюсь.
U-gene
В любом случае
Бредятина
...если "Изучает" является значением некого атрибута результирующего...
меня поразило. "Изучает" - это имя в схеме данных. Оно в запросе может появиться, и, соответственно, в заголовках результат запроса.

Это зря))) Однако. меня устраивает. Итак, верный результат без "Изучает". В остальном все правильно? Прежде, чем говорить откуда берется название производного отношения...
7 июн 13, 14:01    [14406238]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности. А я думаю, что нормализация, как все остальное, что проходит в рамках реляционной модели, к этим непонятным и неопределенным сущностям (и др. концептуальным вещам) отношения вообще не имеет.

Просто фантастика)) При описании РМД у Кодда сущности на каждом шагу. Даже в формальных определениях!:
"Rule 1 (entity integrity): No primary key value of a base relation is allowed to be null or to have a null component"
7 июн 13, 14:08    [14406271]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
PSV100
Сделаю предположение, что на нижнем уровне лежит "чистая" РМД, полная "sql-трансформация" в лоб. Условно, пусть те же классы "Накладные" и "Товары" трансформируются в соответствующие таблицы sql-сервера "Шапки накладных", "Их строки", "Товары".

Я верю U-gene, что это не так.
7 июн 13, 14:10    [14406288]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
U-gene,

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

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

Об этой проблеме косвенно писали где-то ранее, но внимания не акцентировали. В РСУБД иногда вынуждены через одну и ту же таблицу выражать разные прикладные сущности. Причины могут как технические (например, индекс-таблицы, или кластерные таблицы, предопределяют физическую организацию данных, что имеет весомый фактор), так и логические (что, в принципе, не редко). В качестве простого примера возьмём два типа документов: те же "Накладные на отгрузку" и ещё "Акт приёмки". В условной подсистеме "Производство" формируют "накладные отгрузки" продукции, а в подсистеме "склад готовой продукции" эти же накладные выражают "Акт приёмки" (ну, кроме самой физической бумажки, в информационной системе этот "акт" как бы формируется автоматически, но может и иметь расширенный вид, т.е. с дополнительными реквизитами относительно "накладной"). Соответственно, ведь кроме хранения данных есть куча вычислительных операций над ними и т.д., то нередка практика, когда вместо двух разных таблиц (с дублированием и синхронизацией данных) все нужные документы сохраняют в одной, "Документы". Т.е. одна и та же строка в таблице может выражать разные логические документы. Для каждого типа документа обычно требуется свой набор реквизитов, где немало чего общего, так и индивидуального. Но хранят всё вместе, в одной строке таблицы, предполагая (в разумных пределах), что СУБД оптимизируют хранение данных (явные null-данные не занимают место, где-то в заголовке записи делают битовые карты для них, сжимают строки и т.д.).
Для простоты пока не рассматриваем связанные таблицы, как те же "строки" документов.

Теперь я попробую сделать модель в RxO для подобного случая. Мне нужен базовый класс "Документы", и два наследника: "Накладные" и "Акты". Т.е. предполагается, как только выписывается "накладная" она сразу же становится "общим документом", который есть основа для "акта" (или, фактически, это один и тот же документ). Эти "общие документы" в реальности применяются для ряда взаимосвязанных подзадач (не только "накладные" и "акты"), соответственно требуется или закладывается возможность организовать "документы" как общее хранилище.
Таким образом, мне нужна такая вот иерархия:
CREATE CLASS Документы
(   Тип        INTEGER,
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

CREATE CLASS Накладные EXTEND Документы
(
);

CREATE CLASS Акты EXTEND Документы
(
);

Здесь "Накладные" и "Акты" как классы выражают каждый свою прикладную сущность, причём через общего предка "Документы" видно лишь только то, что и "Накладные" и "Акты" имеют одинаковый набор полей, как будто "Документы" всё лишь помогалка для обобщения кода. То, что они как-то связаны ещё и логически, пока это в модели ни как не видно. Более того, как бы в прикладной модели мы сразу же пытаемся для себя через наследование выразить и их физическую модель, т.е. сказать, что "документы" есть общее физическое хранилище одновременно и для "накладных", и для "актов". Но стороннему человеку, глядя на эту модель, всех моих мыслей никак не понять.

К тому же, потомки будут иметь свойство "Тип документа", который уже и так явно выражается через сам класс, как непосредственная сущность. Если не использовать это свойство, то нужны иные косвенные признаки. В ряде простых случаев это работает, например, если в "общих документах" будут только "накладные" и "акты", то одни и те же физические данные, без дополнительной логики, в одном месте мы можем показать в таком виде, как накладные, в другом - как акты.

А вот вся основная сущность нашей прикладной модели, одновременно и физической модели организации данных, уже выражается в так называемых "реализациях", т.е. в уже алгоритмических операторах вида "ALTER Накладные REALIZE ...", которые, по большому счёту, должны где-то быть оформлены в сторонке в непубличной секции вида "imlementation" модуля, вместо "interface".

И теперь весь гемор заключается в этой реализации. Поскольку нам нужно все документы хранить в общем хоронилище, то объекты должны создаваться лишь только для класса "Документы". Соответственно, реализация всех "свойств" у класса "Накладных" должна быть "вычислимая", т.е. при непосредственной выборке из класса "Накладные" мы на самом деле должны извлекать объекты из "документов", т.е. по таким мотивам:
ALTER Накладные REALIZE (Номер, Дата, ...) AS
SELECT Номер, Дата, ...
FROM Документы
WHERE Тип = <такой-то>

Поступаем точно также и для "актов", при этом, скорее всего, будем вынужденны отчасти дублировать код (ибо нет "внешних" методов, "примесей", "интерфейсов" и прочего типового над-классового вынужденного хозяйства).

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

Значит, вынужденны заниматься дублированием данных, чего изначально ни как не хотели. Т.е. в классах "Накладные" и "Акты" мы переопределяем стандартные "методы-триггеры" (которых пока нет, и откровенно говоря, как-то не представляю их сущность как таковую, т.е. эти методы должны указывать на событие (например, "вставку данных"), но при этом отражать то, что событие произошло не в данном конкретном классе, а где-то в предках, причём именно где-то во всей иерархии). И в этих триггерах мы реализуем идентичный (частично копипастный) код, который при создании объекта класса "Документ" будет проверять тип этого документа, и если это накладная, то создаём и объект класса "Накладная". Аналогично для "акта", где будет уже своя корректировка полей под нужды "актов". И реализуем прочие CRUD-операции.

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

Пробуем вариант не создавать объекты для "Документы", а пусть каждый класс-потомок "содержит" сам свои объекты. Да, теперь выборка из "Документы" будет корректна. Те, кто раньше проектировал и уже реализовал работу с общими документами, смогут спать спокойно, им на входе будут все "накладные" и "акты", и пр. вещи, о которых они и не знали, но им и требовалось наладить обработку всего. А вот те, кто реализует работу непосредственно для "накладных" теперь будут договариваться с теми, кто работает над "актами". Ведь изначально предполагалось, что будет общее хранилище, ведь по сути физически это одни и те же данные, но ведь ООП... Теперь ребята занимаются копированием, синхронизацией, занимаются закупкой нового железа...

Причём, обращаю внимание, что рассматриваем случай упрощённо, без тех же "строк" документов, т.е. без "табличных" свойств внутри классов.

Как я понимаю, что мне в этом случае нужно плюнуть на свою "кривую" модель, пойти почитать талмуды про ООП, покурить, снова почитать, и в конечном счёте реализовать всю свою модель в виде одного единственного класса "Документы", который будет выражать и логическую, и физическую модель данных.
И при этом, на самом деле, фактически, основная суть "прикладной" модели уйдёт в комментарии, или в аннотации/атрибуты а-ля java/net (плюс внешняя документация, wiki и т.д.). Т.е. вместо конкретного прикладного DSL, декларативного, в частности, sql-подобного, я на русском/английском рядом буду описывать всё, что есть такое "документы" на самом деле. И в дальнейшем вся работа будет требовать, как минимум, вместо обращения к конкретному классу использовать дополнительные условия отбора по типу документа и т.д.


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


И чтобы уже два раза не вставать. Напомню про название этой темы форума. Не предполагалось ли каких-то механизмов для реализации типовой задачи "гибкой структуры", именно в рамках ООП, без "EAV" над классами?

Т.е. каких-нибудь инвариантных свойств вида: obj["my_property"] := value
В общем, тут важен не КМК какой-то, а опять же концептуально.

Спасибо.
7 июн 13, 17:00    [14407600]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11485
Мурыч
Почему Вы подумали что это ORM?
Пока автор использует в качестве хранилища реляционную СУБД - это ORM.
Реализует нативное хранилище объектов - можно будет оценить содеянное.
7 июн 13, 17:20    [14407758]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11485
U-gene
1) Вот из-за таких вопросов я и отказываюсь лезть на концептуальный уровень.
Напрасно.
Взамен я предлагаю систему, где есть и классы и таблицы
"Генетики создали гибрид капусты и редьки. Проблема в том, что у него листья редьки и корень капусты"
2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности.
В процессе нормализации устраняется избыточность данных и определяются связи.
Не бывает отдельно строк накладной и заголовка.
Это вас кто-то обманул.
И, нормализовав данные накладной, можно продолжать думать о ней, как о едином целом. А в RxO вы можете эту мысль реализовать.
Угу. Как минимум двумя способами - с денормализацией и без.
это одна система, а не попытка насильно поженить две разные
Я посмотрю на ваш оптимизм, когда ваша система встанет в промышленную эксплуатацию на реальных объёмах данных.
7 июн 13, 17:28    [14407782]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11485
PSV100
И в чём же именно концептуальная ошибка?
В способе стыковки.
Т.к. программистам "сложно" работать с DML - изобретаются различные костыли, отображающие объекты на схему базы.
7 июн 13, 17:30    [14407792]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
vadiminfo
PSV100
"модель данных должна быть одна и та же на концептуальном и логическом уровнях" - то и нет потребности .....

То и нет потребности в разных уровнях: раз модель одна и та же, то они (уровни) ни чем и не отличаются.

Наверное, на самом деле имелось в виду не одна и та же модель, а один и тот же тип модели. Напрмер, ООМД на всех уровнях, тогда как для РМД на концтуальном уровне ER. Естественно, в первоисточниках речь о недостатке, а не об обязательности.

Возможно, Вам лучше уточнить эту позицию у оригинального автора, у коллеги Бредятина.

Я согласен с тем, что, как правило, требуются свои модели для разных уровней, но при этом тип моделей может быть один и тот же. И мой пост выше показал пример, где напрашивается наличие разных моделей для каждого уровня, логического и физического (пусть будет так упрощённо, я не силён в терминологии). Тип этих моделей может быть один, а-ля "мейнстрим-ООП".
vadiminfo
Но не очевидно, что это и недостаток во всех отношениях.
Специализированные в своих областях (в данном случае уровнях), часто лучше комбайна в этих областях.
В UML мы же с удовольствием юзаем разные диаграммы.

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

P.S. Ну, лично я UML не очень-то с удовольствием юзаю, или частично, но это и мои личные тараканы, не о них речь.
7 июн 13, 17:35    [14407811]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
Basil A. Sidorov
PSV100
И в чём же именно концептуальная ошибка?
В способе стыковки.
Т.к. программистам "сложно" работать с DML - изобретаются различные костыли, отображающие объекты на схему базы.


Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.

Впрочем, здесь опять путаница в терминологии, я не теоретик. Думаю, что здесь найдутся те, кто сможет все термины разложить по полочкам.
7 июн 13, 17:44    [14407841]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11485
PSV100
Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.
Да, ORM - ошибка природы.
Вас удивляет, что ошибка существуют и вполне успешно? Ну так не удивляйтесь - это вполне нормально.
7 июн 13, 18:03    [14407892]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
PSV100

тип моделей может быть один и тот же. .

Это означает, что может быть и разным.

Т.е. в любом случае мыстль "модель данных должна быть одна и та же на концептуальном и логическом уровнях", скорее всего, связана с какой-то идеей впарить что РБД не БД, или тому подобной ахинеей.
Поскольку де мол БД не дложна, а РБД так поступает.
7 июн 13, 18:35    [14407950]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
vadiminfo
PSV100
тип моделей может быть один и тот же. .

Это означает, что может быть и разным.

Т.е. в любом случае мыстль "модель данных должна быть одна и та же на концептуальном и логическом уровнях", скорее всего, связана с какой-то идеей впарить что РБД не БД, или тому подобной ахинеей.
Поскольку де мол БД не дложна, а РБД так поступает.


Ага, теперь мне стало понятно, о чём речь. Вынужден уточнить.

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

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

Извиняюсь, что изначально ввёл в заблуждение.


Вынужден привести пример относительно несложных моделей на разных уровнях, дающих меньше проблем. Естественно, чем ближе к сути, тем проще жить. Поэтому свой пример (точнее кусочек) из своего поста выше на счёт "документов", представлю так. Физический уровень выразим внутри БД, на родном SQL (точнее псевдо-SQL):
CREATE TABLE Документы
(   Тип        INTEGER,
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

Логическая модель у нас в клиентском приложении. Представим его на псевдокоде:
-- тип "структура", отражающий конкретные "накладные":
sctruct Накладные {
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...      
}
ON TABLE Документы;

-- значение поля "Тип" в таблице "Документы", указывающее на "Накладные"
const ТипНакладных = 4;

-- хранение массива накладных в памяти:
var Реестр: array of Накладные;

-- переменные, указывающие на даты для целевого периода отбора данных:
var Начало: DATETIME = to_date("01.06.2013");
var Конец:  DATETIME = to_date("30.06.2013");

-- загружаем данные:
EXEC SQL BEGIN
    START TRANSACTION;

    SELECT
        Номер, Дата, Поставщик, ...
    FROM Накладные.TABLE
    WHERE Тип = :ТипНакладных AND (Дата BETWEEN :Начало AND :Конец)
    INTO Реестр;

    COMMIT;
END;

-- дальше используем данные
...

Не говорю об архитектуре приложения, тут от консольных утилит (запустились, отработали, выгрузились) до серваков приложений. А вот такие а-ля MS-LINQ-технологии были ещё при царе горохе, когда производители SQL-серверов делали для "мейнстрима" свои препроцессоры, например, для С/С++ (embedded SQL). Так что, бредокод выше не так уж и далёк от действительности, на самом деле. И производители ещё тогда думали о каком-то вменяемом "маппинге".

Basil A. Sidorov
PSV100
Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.
Да, ORM - ошибка природы.
Вас удивляет, что ошибка существуют и вполне успешно? Ну так не удивляйтесь - это вполне нормально.


Код клиента выше вполне себе ORM, т.е. формируем коллекцию именно объектов на основе реляционной таблицы в БД.
7 июн 13, 21:20    [14408342]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
Мурыч
Почему Вы подумали что это ORM?
Пока автор использует в качестве хранилища реляционную СУБД - это ORM.
Реализует нативное хранилище объектов - можно будет оценить содеянное.
Уважаемый Basil. Вот Вы вроде такой умный :) , а простой вещи понять не можете (впрочем не только Вы). Я не использую реляционную СУБД как хранилище. У меня РСУБД - это, в первую очередь, исполняющая система. а тот факт, что объекты персистентные, всего лишь следствие того, что память в этой исполняющей системе персистентная. В моей системе РБД настолько же нативное хранилище данных объектов, как линейное ОЗУ для программ, написанных на традиционных ОО языках (прочитайте это предложение еще раз... разве Вы не согласны с тем, что именно линейное ОЗУ является нативной средой для объектов? и на хранилище оно не тянет, только потому, что ОЗУ, как правило, не является персистентным.).

Думать надо по-другому.Забудьте про СУБД как про то, что стоит где то сбоку и используется только для хранения данных. Представьте себе компьютер с ассоциативной памятью, который динамически может создавать новые ассоциации. Задача - создать для него ОО транслятор. Создали. А тут дополнительный профит появился - эта ассоциативная память заодно является персистентной, значит объекты персистентные, значит можно использовать эту систему как СУБД.

Я везде использую хорошо известный термин "трансляция" и считаю, что люди меня понимают(как правило, так оно и есть).Но, оказывается, некоторые настолько погрязли в маппинге, что ничего другого не видят. Например Бредятина. И здесь, и в других местах я неоднократно объяснял ему, что речь идет о трансляции ОО-команд, а он считает, что всего лишь игра слов, и, поэтому, тут же начинал говорить про "МД верхнего уровня+маппинг+РМД". На самом же деле, если для вас трансляция и маппинг - одно и то же, то про какие-то более тонкие материи вообще говорить не получится. На самом деле, разница между этими понятиями приблизительно такая же как между "системой программирования" и "программируемой системой". Вы КМК называете RxO ОРМом только потому, что базовые идеи CS забыли.

Именно эти вещи я имел в виду, когда говорил, что "бытиё определяет сознание". Кстати, всегда думал, что разница между программистами и спецами по БД высосана из пальца. Оказывается, я ошибался.
7 июн 13, 23:48    [14408808]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
PSV100
U-gene,

Всё таки, хотелось бы понять сущность более низкого уровня, чем классы.

Сделаю предположение, что на нижнем уровне лежит "чистая" РМД, полная "sql-трансформация" в лоб. Условно, пусть те же классы "Накладные" и "Товары" трансформируются в соответствующие таблицы sql-сервера "Шапки накладных", "Их строки", "Товары". Проблемы отчасти связаны с тем же "несимметричным доступом", о котором опять же говорил коллега Бредятина. Если коротко, то реальная практика применения реляционных СУБД часто вынуждает в тех же строках накладных держать реквизиты "дата документа", "код поставщика" и т.п., т.е. дублировать некоторые поля из "шапки" накладной. Таким образом достигается возможность уменьшить потребность в обращении к "шапкам", когда над "строками" документов выполняются массовые операции (расчёт типовых агрегатных оборотов, расчёт цен и т.п.), т.е. в запросах не будет соединения с "шапками", что уменьшает нагрузку и т.д. Плата за это - дублирование данных, больше дискового пространства, лишние индексы. Но, в целом, "по отрасли" это терпимая плата, и вот уже много лет реляционные СУБД относительно успешно применяют, и считают их универсальными.
Негативный момент - якобы нарушается идеологическая гармония РМД, т.е. в реальной практике добиться идеальной нормализации затруднительно.

В этом случае, проблема в RxO, фактически, переносится автоматом. Поскольку через классы задают некую прикладную модель, при этом же она выражает и как бы конечную модель (логическую) в БД, то часто классы "накладных" на самом деле вынужденны будут задавать как-то так:
CREATE CLASS Накладная
( 	Номер      STRING,
	Дата  	   DATETIME,
	Поставщик  INTEGER,
	...
	Содержимое SET OF
	( 	
		Дата  	   DATETIME,
		Поставщик  INTEGER,
		Товар      INTEGER,
		...
	)
);

т.е. с дублированием полей в "строках" из "шапки". Нарушается идеологическая чистота прикладного моделирования.

Сейчас я подозреваю, что в прототипе сегодня на нижнем уровне работает некая прикладная система (пусть будет а-ля EAV, не важно), к тому же вряд ли реализована полная трансформация в SQL, скорее всего, работает и свой интерпретатор. Но прототип есть прототип, пока идёт обкатка концепций и т.д. Но, если и в финальном продукте система будет реализована поверх "EAV", то разработчикам в любом случае нужно понимать всю логику до конца, и управлять всеми нюансами. Если будет полная трансформация в "чистою" РМД, то получим проблемы, указанные выше. Если в иную РМД-форму, то тоже необходимо понимать как.

Т.е. если проектировать, моделировать, программировать в условиях полной абстракции уровней, в полном игноре "соседей", то можем в итоге и получить "игнор".

Вы оценивали подобные проблемы, не приведёт ли это к тому, что часто будут вынуждены использовать Ваши планируемые таблицы, вместо классов?
Забудьте про EAV (чур меня). Ваша накладная в лоб отобразится в две таблицы. Думаю, что в реальной практике такое дублирование (прям один-в-один, как Вы изобразили) тоже может использоваться с теми же целями.
8 июн 13, 00:12    [14408866]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
PSV100
CREATE CLASS Документы
( Тип INTEGER,
Номер STRING,
Дата DATETIME,
Поставщик INTEGER,
...
);

CREATE CLASS Накладные EXTEND Документы
(
);

CREATE CLASS Акты EXTEND Документы
(
);


Ок. А дальше все гораздо проще. Где-нибудь делаем

ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.

Всё. Реализации компонентов и методов тоже наследуются, пока не переопределим. Значит и в объектах классов "Акты" и "Документы" эти компоненты тоже будут хранимыми. Ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели" :).
8 июн 13, 00:31    [14408908]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить