powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Хранение данных с гибкой структурой и запросы к ним
257 сообщений из 257, показаны все 11 страниц
Хранение данных с гибкой структурой и запросы к ним
    #38247523
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Необходима СУБД, удовлетворящая следующим требованиям (вкратце):

пользователь с помощью графического интерфейса добавляет информацию о любых предметах (сущностях) (дом(номер дома количество квартир...), автомобиль (масса, макс. скорость, цена...), стиральная машинка (объем, энергопотребление, цвет...)), а затем может работать с этими сущностями:
— добавлять-редактировать экземпляры (записи, данные);
— создавать связи между сущностями (при удалении информации о доме, удяляется вся информация о стиралках, установленных в нем);
— составлять запросы к этим сущностям, например: «найти все зеленые стиральные машины в квартирах домов с четными номерами на 5-м этаже» (с помощью QBE, либо, в особых случаях, с помощью встроенного языка запросов СУБД).

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

Я уже озадачивался этим вопросом и даже остановился на вот таком решении — habrahabr.ru/post/164803/ (вкратце: хранить экземпляры сущностей в одной таблице в формате xml, и делать к ним sql-запросы с использованием xpath).
Вроде все неплохо, но криво получается реализация связей между сущностями (приходится использовать вспомогательную таблицу для хранения соответствий, либо заивать ключи в xml).

Но недавно в очередной раз наткнулся на Neo4j и подумываю, чтобы заюзать ее.

Подскажите, может ли она подойти к подобной задаче?
Какие есть другие варианты?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247568
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НКакие есть другие варианты?
Эта задача вполне укладывается в EAV на любой СУБД, но тебе стоит посмотреть на Cache. Оно
как раз пропагандируется для таких структур.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247704
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovМаксим НКакие есть другие варианты?
Эта задача вполне укладывается в EAV на любой СУБД, но тебе стоит посмотреть на Cache. Оно
как раз пропагандируется для таких структур.


Про EAV согласен, но в моем случае мало подходит.
Cache это круто конечно, а что-нибудь для бедных?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247711
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НПро EAV согласен, но в моем случае мало подходит.
Да ну?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247759
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovМаксим НПро EAV согласен, но в моем случае мало подходит.
Да ну?


Планируется построение довольно сложных запросов к пользовательским сущностям (несколько уровней вложенности, фильтры и т.д.). Причем как с использованием QBE, так и руками пользователей.
С EAV это конечно возможно, но запросы будут гораздо сложнее, их тяжело поддерживать и оптимизировать. Не все радужно с индексированием. Тогда как, используя xml, можно проиндексировать элементы нужной сущности.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247794
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НС EAV это конечно возможно, но запросы будут гораздо сложнее

С какого бы перепугу?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247849
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovМаксим НС EAV это конечно возможно, но запросы будут гораздо сложнее

С какого бы перепугу?


Не хотелось бы устраивать очередную EAV'шную баталию...
Инфы много, мне нравится например эта статья - https://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

Т.е. для того чтобы банально приджойнить пару таблиц и выбрать несколько полей (3 строчки, как бы это было в нормальной реляционке), нужно написать гораздо больше кода. Неговоря уже о сложных запросах.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247878
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НТ.е. для того чтобы банально приджойнить пару таблиц и выбрать несколько
полей (3 строчки, как бы это было в нормальной реляционке), нужно написать гораздо больше
кода.
Ну, если головной мозг имеет размер и консистенцию грецкого ореха, как у автора статьи, то
конечно. Есть у застарелых кодеров такая привычка забивать шурупы молотком, потому что они
20 лет работали с гвоздями. Если бы он не стремился маниакально разворачивать данные
"вширь", то его второй запрос имел бы точно такой же размер, как и первый. И выполнялся бы
так же быстро.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247960
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

На ты бы рассказал, например, как "с развернутыми на 90 градусов" данными задействовать серверную сортировку. А то все обзываешься только.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247974
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmНа ты бы рассказал, например, как "с развернутыми на 90 градусов" данными
задействовать серверную сортировку.
С одноколоночным резалт-сетом и рассказывать нечего. А для многоколоночных клиентская
сортировка более user-friendly. Сам же знаешь: все хотят чтобы кликнул на заголовок грида,
а оно взяло и отсортировалось по этому столбцу. А те кто не хотят просто слишком запуганы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247987
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovvvmНа ты бы рассказал, например, как "с развернутыми на 90 градусов" данными
задействовать серверную сортировку.
С одноколоночным резалт-сетом и рассказывать нечего. А для многоколоночных клиентская
сортировка более user-friendly. Сам же знаешь: все хотят чтобы кликнул на заголовок грида,
а оно взяло и отсортировалось по этому столбцу. А те кто не хотят просто слишком запуганы.

Какой ты скользкий...
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38247995
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н,

QBE - это для дураков-юзеров образца 1970 года. Визуальные построители фильтров куда удобнее и продуктивнее.
А кодер один черт sql использовать должен.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248017
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmМаксим Н,

QBE - это для дураков-юзеров образца 1970 года. Визуальные построители фильтров куда удобнее и продуктивнее.
А кодер один черт sql использовать должен.
Если не сложно покажите ссыль какую-нибудь с примером, как это может выглядеть?
Извиняюсь за глупый вопрос, а как можно реализовать мехнизм связи между сущностями(таблицами) с помощью "построителей фильтров"?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248072
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov А для многоколоночных клиентская
сортировка более user-friendly...

На ЕАВе "клинтская " более user-friendly?
На ЕАВе, наверное, во многих случаях "клинтская " более user-friendly.

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

Dimitry Sibiryakov .А те кто не хотят просто слишком запуганы.

Ну не все же готовы вместо простых селектов писать "циклы", динамические запросы ..... Зачем буржуа придумывал для нас МД с декларативными и ассоциативными языками БД? Чтобы бы мы изобретали как вместо этого циклы написать.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248107
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoНу не все же готовы вместо простых селектов писать "циклы", динамические
запросы
Ты это об чём? Какие "циклы" пишут, например, пользователи, кликающие на заголовок столбца
в "Проводнике" для сортировки по нему? И чем провинились пользователи говноподелок,
аффтары которых не хотят предоставить им такой же сервис?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248114
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
Ты это об чём? Какие "циклы" пишут, например, пользователи, кликающие на заголовок столбца
в "Проводнике" для сортировки по нему? И чем провинились пользователи говноподелок,
аффтары которых не хотят предоставить им такой же сервис?

Я в основом про тех пользователей, которые аффторы. Тех кто разрабатывает и сопровождает.
Впрочем, селекты (а тм болеe QBE) для отчута могут налабать и конечные пользоватли.
Тема же, скорее, про БД, а не про интерфейсы.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248133
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovvadiminfoНу не все же готовы вместо простых селектов писать "циклы", динамические
запросы
Ты это об чём? Какие "циклы" пишут, например, пользователи, кликающие на заголовок столбца
в "Проводнике" для сортировки по нему? И чем провинились пользователи говноподелок,
аффтары которых не хотят предоставить им такой же сервис?

Придется тащить на клиента сразу все данные. Как минимум - те, по которым делать сортировку. Обработка "кликов" на сервере позволяет вытаскивать не весь результат сразу.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248140
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmПридется тащить на клиента сразу все данные. Как минимум - те, по которым делать
сортировку. Обработка "кликов" на сервере позволяет вытаскивать не весь результат
сразу.
Хочешь мучить сервер - выбирай атрибут сортировки отдельным запросом, а с ним уже джоинь
все остальные. В чём проблема-то?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248255
eny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eny
Гость
Максим Н,

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

Вместо того, чтобы написать нормальный фреймворк экранирующий SQL Server выдумываются всякие недоинструменты.

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

Раньше, порог вхождения в отрасль был значительно выше и таких глупостей было меньше
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248299
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eny,

Большое спасибо за советы, учту.
Но ИМХО Вашу критику предложенного метода на хабре (кстати только одного из них, и от которого я в конце концов отказался уже) Вы ни чем не обосновали (был бы очень благодарен за это).
И альтернативных вариантов предложено тоже не было (так же был бы весьма благодарен), кроме того как почитать "классику".

авторВместо того, чтобы написать нормальный фреймворк экранирующий SQL Server
А вот здесь можно поподробнее?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248356
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovvvmПридется тащить на клиента сразу все данные. Как минимум - те, по которым делать
сортировку. Обработка "кликов" на сервере позволяет вытаскивать не весь результат
сразу.
Хочешь мучить сервер - выбирай атрибут сортировки отдельным запросом, а с ним уже джоинь
все остальные. В чём проблема-то?..

Как это - "выбирай и джойнь"? :)

А как же твоя 12031140 схема "тянем все подряд, клиент разберётся"?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248378
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmА как же твоя схема "тянем все подряд, клиент разберётся"?
Она для разумных людей, разумно распределяющих нагрузку между сервером и клиентом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248396
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovvvmА как же твоя схема "тянем все подряд, клиент разберётся"?
Она для разумных людей, разумно распределяющих нагрузку между сервером и клиентом.

Где таких взять.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248402
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmГде таких взять.
"Бабу Ягу со стороны брать не будем, вырастим в своём коллективе." (с) КН
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248543
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Максим ННеобходима СУБД, удовлетворящая следующим требованиям (вкратце):
Это не СУБД, а фраймворк. Попросите, м.б. кто-то и поделится. Если нет, то делайте сами. В основе ессно EAV. СУБД любая.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248723
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод.... Если нет, то делайте сами. В основе ессно EAV.

Особенно должна вдохновлять идея "делать самим" с учетом:

[Максим Н]Про EAV согласен, но в моем случае мало подходит.
[/quot]
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248768
eny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eny
Гость
Максим Нeny,

Большое спасибо за советы, учту.
Но ИМХО Вашу критику предложенного метода на хабре (кстати только одного из них, и от которого я в конце концов отказался уже) Вы ни чем не обосновали (был бы очень благодарен за это).
И альтернативных вариантов предложено тоже не было (так же был бы весьма благодарен), кроме того как почитать "классику".

авторВместо того, чтобы написать нормальный фреймворк экранирующий SQL Server
А вот здесь можно поподробнее?

статья на хабре вообще ни о чем, чего-то там у пацана с базами не срослось и начались сопли пузырями

По факту я сам фреймворк написал, и еще с три-четыре всяких реализаций видел, где все можно поменять и храниться все в реляционных базах
При небольшом умении программировать хранимки и проектировать структуру БД, все можно сделать настраиваемым. вплоть до динамической генерации create table/alter table/drop table

как пример открытого есть vtiger CRM - вроде открытый исходник на php и my sql - дешево и сердито
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38248801
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
enyПо факту я сам фреймворк написал, и еще с три-четыре всяких реализаций видел, где все можно поменять и храниться все в реляционных базах

Вы сейчас о EAV говорите?

enyПри небольшом умении программировать хранимки и проектировать структуру БД, все можно сделать настраиваемым. вплоть до динамической генерации create table/alter table/drop table

Или о физическом создании отдельной таблицы для каждой пользовательской сущности?
Ведь в многопользовательской среде с этим проблемы могут быть, да и вообще create(drop) table это дорогая операция (в зависимости от СУБД конечно) и дергать ее при каждом пользовательском чихе (очобенно если их будет больше одного) не очень прильщает. Поправьте если не прав.

enyкак пример открытого есть vtiger CRM - вроде открытый исходник на php и my sql - дешево и сердито
Спасибо, посмотрю.


ПС
Я о том, что проблема достаточно распространенная (тот же самый каталог товаров избитый например), а вот универсальных готовых решений не очень много.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38249760
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н,

Ну что значит "дорогая операция"?
Рядовой пользователь создавать/удалять сущности(таблички)/атрибуты(поля) не должен иметь прав.

Только специальный.

Сделай систему со словарем: чтобы было описание сущностей, их полей, и связей между сущностями. А сами сущности реализуй в физических табличках. Система будет иметь и словарь данных, и не будет иметь eav - проблем с производительностью.
Процесс модификации таких пользовательских метаданных можно вынести в особую сессию: "Всем выйти из моей программы!". Набрать в процессе редактирования таких "метаданных" пакет изменений, потом проверить, что ты единственный, кто подконнектился, и выполнить итоговый модифицирующий скрипт. Можно отконнекчивать прочих пользователей административными методами, а можно специальное сообщение рассылать. Варианты есть, реализовать несложно.
Так часто делают. Не для всех СУБД получится "в лоб": к примеру, в MS SQL нехилое ограничение на суммарный размер записи и т.д. В любом случае, обходные пути есть.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38249883
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmв MS SQL нехилое ограничение на суммарный размер записи и т.д.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE T1(col1 varchar(8000), col2 varchar(8000), col3 varchar(8000))
GO

INSERT T1 (col1, col2, col3) VALUES(REPLICATE('A', 8000), REPLICATE('B', 8000), REPLICATE('C', 8000))
GO

SELECT DATALENGTH(col1) + DATALENGTH(col2) + DATALENGTH(col3) FROM T1
GO

DROP TABLE T1
GO




Код: plaintext
1.
2.
3.
4.
5.
(1 row(s) affected)

-----------
24000

(1 row(s) affected)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38249890
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НВедь в многопользовательской среде с этим проблемы могут быть, да и вообще create(drop) table это дорогая операция (в зависимости от СУБД конечно) и дергать ее при каждом пользовательском чихе (очобенно если их будет больше одного) не очень прильщает.Все в этом мире относительно. Если каждый объект сам по себе и имеет свою неповторимую структуру, то создавать таблицу по каждому чиху - смысла нет. Но правда и какой-либо словарь в этом случае мало поможет. Если же объекты допускают словарное описание, то есть нормально классифицируются в некоторое количество типов, то создание таблицы на каждый тип вполне возможно и никакой убийственной нагрузки не создаст. Число возможных типов и их атрибутов, очень легко оценить, и сомневаюсь, что в процессе эксплуатации модификация словаря будт происходить чаще раза в день.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38250680
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinvvmв MS SQL нехилое ограничение на суммарный размер записи и т.д.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE T1(col1 varchar(8000), col2 varchar(8000), col3 varchar(8000))
GO

INSERT T1 (col1, col2, col3) VALUES(REPLICATE('A', 8000), REPLICATE('B', 8000), REPLICATE('C', 8000))
GO

SELECT DATALENGTH(col1) + DATALENGTH(col2) + DATALENGTH(col3) FROM T1
GO

DROP TABLE T1
GO




Код: plaintext
1.
2.
3.
4.
5.
(1 row(s) affected)

-----------
24000

(1 row(s) affected)

Ну вот и ладушки: считай, что "в мс скл сервер ограничений на суммарный размер записи нет"
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38250687
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО, тема должна быть в разделе "пректирование", а не "сравнение".
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38255468
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н,

авторНе хотелось бы устраивать очередную EAV'шную баталию...
Инфы много, мне нравится например эта статья - https://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

EAV можно реализовать по-разному.
Вы ссылаетесь на вырожденный случай, когда и данные, и метаданные, и сущности, и атрибуты (columns) лежали в одной таблице Data.
Есть вариант EAV на три таблицы, есть на пять таблиц и более.
Например, набор табличек:
- типы сущностей
- сущности
- типы связей сущностей
- связи сущностей
- типы атрибутов
- шаблоны (список атрибутов для типа сущности)
- таблица значений.
При таком наборе таблиц в несколько раз меньше джойнов потребуется, особенно, если в таблицу сущностей включить базовый набор атрибутов (название и пр.).
Здесь на форуме упоминалось успешное применение EAV-систем.
В Вашем случае авторпользователь с помощью графического интерфейса добавляет информацию о любых предметах (сущностях) (дом(номер дома количество квартир...), автомобиль (масса, макс. скорость, цена...), стиральная машинка (объем, энергопотребление, цвет...)), а затем может работать с этими сущностями:
— добавлять-редактировать экземпляры (записи, данные);
— создавать связи между сущностями (при удалении информации о доме, удяляется вся информация о стиралках, установленных в нем);
— составлять запросы к этим сущностям, например: «найти все зеленые стиральные машины в квартирах домов с четными номерами на 5-м этаже» (с помощью QBE, либо, в особых случаях, с помощью встроенного языка запросов СУБД).

не похоже, что речь идет о гигабайтах данных, поэтому согласен с _мод:
авторЭто не СУБД, а фраймворк. Попросите, м.б. кто-то и поделится. Если нет, то делайте сами. В основе ессно EAV. СУБД любая.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38257298
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Animotron - ещё один взгляд на альтернативную жизнь (плюс здесь и здесь ). Модератор: как-то на скрытую рекламу смахивает, если не будет пояснений - пост сотру
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38258519
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Модераторкак-то на скрытую рекламу смахивает, если не будет пояснений - пост сотру

Лично я к этому проекту не имею никакого отношения. Вот чего желает ТС:
Максим ННеобходима СУБД, удовлетворящая следующим требованиям (вкратце):

пользователь с помощью графического интерфейса добавляет информацию о любых предметах (сущностях) (дом(номер дома количество квартир...), автомобиль (масса, макс. скорость, цена...), стиральная машинка (объем, энергопотребление, цвет...)), а затем может работать с этими сущностями:
— добавлять-редактировать экземпляры (записи, данные);
— создавать связи между сущностями (при удалении информации о доме, удяляется вся информация о стиралках, установленных в нем);
— составлять запросы к этим сущностям, например: «найти все зеленые стиральные машины в квартирах домов с четными номерами на 5-м этаже» (с помощью QBE, либо, в особых случаях, с помощью встроенного языка запросов СУБД).

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

Подскажите, может ли она подойти к подобной задаче?
Какие есть другие варианты?

Именно всё это и имеется в этом проекте, в т.ч. как раз поверх Neo4j. Причём это не только некая альтернатива решениям на основе реляционных баз (включая и для EAV), но и, в целом, другой взгляд на разработку информационных систем (отчасти Акссессо-подобный). Я не в курсе, насколько продукт пригоден для использования (думаю, что не очень), но проект интересен, прежде всего, концептуально. Особенно привлекательны способы обработки данных, что можно взять себе на вооружение, причём не только в рамках какой-то NoSQL. Весьма рекомендую ознакомиться.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38269146
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Модераторкак-то на скрытую рекламу смахивает, если не будет пояснений - пост сотру

Лично я к этому проекту не имею никакого отношения. Вот чего желает ТС:
Максим ННеобходима СУБД, удовлетворящая следующим требованиям (вкратце):

пользователь с помощью графического интерфейса добавляет информацию о любых предметах (сущностях) (дом(номер дома количество квартир...), автомобиль (масса, макс. скорость, цена...), стиральная машинка (объем, энергопотребление, цвет...)), а затем может работать с этими сущностями:
— добавлять-редактировать экземпляры (записи, данные);
— создавать связи между сущностями (при удалении информации о доме, удяляется вся информация о стиралках, установленных в нем);
— составлять запросы к этим сущностям, например: «найти все зеленые стиральные машины в квартирах домов с четными номерами на 5-м этаже» (с помощью QBE, либо, в особых случаях, с помощью встроенного языка запросов СУБД).

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

Подскажите, может ли она подойти к подобной задаче?
Какие есть другие варианты?

Именно всё это и имеется в этом проекте, в т.ч. как раз поверх Neo4j. Причём это не только некая альтернатива решениям на основе реляционных баз (включая и для EAV), но и, в целом, другой взгляд на разработку информационных систем (отчасти Акссессо-подобный). Я не в курсе, насколько продукт пригоден для использования (думаю, что не очень), но проект интересен, прежде всего, концептуально. Особенно привлекательны способы обработки данных, что можно взять себе на вооружение, причём не только в рамках какой-то NoSQL. Весьма рекомендую ознакомиться.

Спасибо, именно эти статьи и привели меня к мысле попробовать заюзать графовую базу для таких дел. К сам ому Animotron'у я еще не готов, а вот Neo4j, почему бы и нет.
Зафигачить EAV и радоваться жизни это не проблема, только вот как то надоело, интересно решить данную задачу подругому, с использованием более подходящих для этого инструментов (или выяснить для себя, что это не так), поэкспериментировать (тем более текущий проект позволяет пока).
Если кому будет интересно могу отписаться о своей попытке, когда будут результаты.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38269151
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DirksDRМаксим Н,

авторНе хотелось бы устраивать очередную EAV'шную баталию...
Инфы много, мне нравится например эта статья - https://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

EAV можно реализовать по-разному.
Вы ссылаетесь на вырожденный случай, когда и данные, и метаданные, и сущности, и атрибуты (columns) лежали в одной таблице Data.
Есть вариант EAV на три таблицы, есть на пять таблиц и более.
Например, набор табличек:
- типы сущностей
- сущности
- типы связей сущностей
- связи сущностей
- типы атрибутов
- шаблоны (список атрибутов для типа сущности)
- таблица значений.
При таком наборе таблиц в несколько раз меньше джойнов потребуется, особенно, если в таблицу сущностей включить базовый набор атрибутов (название и пр.).
Здесь на форуме упоминалось успешное применение EAV-систем.
В Вашем случае авторпользователь с помощью графического интерфейса добавляет информацию о любых предметах (сущностях) (дом(номер дома количество квартир...), автомобиль (масса, макс. скорость, цена...), стиральная машинка (объем, энергопотребление, цвет...)), а затем может работать с этими сущностями:
— добавлять-редактировать экземпляры (записи, данные);
— создавать связи между сущностями (при удалении информации о доме, удяляется вся информация о стиралках, установленных в нем);
— составлять запросы к этим сущностям, например: «найти все зеленые стиральные машины в квартирах домов с четными номерами на 5-м этаже» (с помощью QBE, либо, в особых случаях, с помощью встроенного языка запросов СУБД).

не похоже, что речь идет о гигабайтах данных, поэтому согласен с _мод:
авторЭто не СУБД, а фраймворк. Попросите, м.б. кто-то и поделится. Если нет, то делайте сами. В основе ессно EAV. СУБД любая.


Спасибо за рекомендации. Я в принципе знаком с EAV, но почитаю еще, может чего то не понимаю или не правильно использую.
А как бы могла быть решена данная задача средствами Cashe ?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38269157
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov AndreyМаксим НВедь в многопользовательской среде с этим проблемы могут быть, да и вообще create(drop) table это дорогая операция (в зависимости от СУБД конечно) и дергать ее при каждом пользовательском чихе (очобенно если их будет больше одного) не очень прильщает.Все в этом мире относительно. Если каждый объект сам по себе и имеет свою неповторимую структуру, то создавать таблицу по каждому чиху - смысла нет. Но правда и какой-либо словарь в этом случае мало поможет. Если же объекты допускают словарное описание, то есть нормально классифицируются в некоторое количество типов, то создание таблицы на каждый тип вполне возможно и никакой убийственной нагрузки не создаст. Число возможных типов и их атрибутов, очень легко оценить, и сомневаюсь, что в процессе эксплуатации модификация словаря будт происходить чаще раза в день.

В том то и дело я пока не могу это оценить.
Предполагается что то наподобие как в Экселе: т.е. пользователь может создать Лист, на нем разместить таблицу(ы), заполнить тестовыми данными, что то посчитать, а потом удалить (может даже не сохраняя), а может сохранить и работать с ней годами, добавляя данные, формулы, зависимые Листы, графики и всячески усложняя.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38269161
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НПредполагается что то наподобие как в Экселе
А если нужен Эксель, так и ступай к Экселю. (с) почти НВГ.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38269169
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovМаксим НПредполагается что то наподобие как в Экселе
А если нужен Эксель, так и ступай к Экселю. (с) почти НВГ.


1. Нужны запросы к тому что пользователь "надизайнил", причем как графический построитель, так и возможность написать их ручками
2. Нужен Веб-интерфейс
3. Нужен какой никакой контроль целостности, описание схемы (для построения интерфеса например)
4. Ну так же вопросы производительности, масштабируемости и пр.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38269374
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н1. Нужны запросы к тому что пользователь "надизайнил", причем как графический построитель, так и возможность написать их ручками
2. Нужен Веб-интерфейс
3. Нужен какой никакой контроль целостности, описание схемы (для построения интерфеса например)
4. Ну так же вопросы производительности, масштабируемости и пр.

Вы только что описали MS SQL Manager ;-)
Попробуйте EMS PostgreSQL Manager.

P.S. Для FireBird есть IBExpert - она еще и бесплатная.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38270371
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulМаксим Н1. Нужны запросы к тому что пользователь "надизайнил", причем как графический построитель, так и возможность написать их ручками
2. Нужен Веб-интерфейс
3. Нужен какой никакой контроль целостности, описание схемы (для построения интерфеса например)
4. Ну так же вопросы производительности, масштабируемости и пр.

Вы только что описали MS SQL Manager ;-)
Попробуйте EMS PostgreSQL Manager.

P.S. Для FireBird есть IBExpert - она еще и бесплатная.

"Пользователь" там такого "надизайнит" - мама не горюй.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38270526
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulВы только что описали MS SQL Manager ;-)Это вечная проблема фреймворков - каждый разработчик фреймворка пытается сделать некое управление "гибкой структурой", при этом не желает или не может оценить степень необходимой пользователю гибкости.
В итоге получается некий велосипед, который для программиста уже не удобен, так как слишком сильно его ограничивает, а для пользователя еще не удобен, так как требует слишком глубокого понимания основ программирования.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38271221
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvm"Пользователь" там такого "надизайнит" - мама не горюй.

Ну Access предназначен для конечного пользователя. ;-)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38271223
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov Andreymad_nazgulВы только что описали MS SQL Manager ;-)Это вечная проблема фреймворков - каждый разработчик фреймворка пытается сделать некое управление "гибкой структурой", при этом не желает или не может оценить степень необходимой пользователю гибкости.
В итоге получается некий велосипед, который для программиста уже не удобен, так как слишком сильно его ограничивает, а для пользователя еще не удобен, так как требует слишком глубокого понимания основ программирования.

Полностью согласен!
Гибкость пользователю не нужна.
Ему нужна только одна кнопка "ЗАШИБИСЬ".
Нажал на нее и "ЗАШИБИСЬ".

<:o)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38271234
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulvvm"Пользователь" там такого "надизайнит" - мама не горюй.

Ну Access предназначен для конечного пользователя. ;-)
Их (конечных пользователей акцесса) несколько подвидов.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38271310
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov Andreymad_nazgulВы только что описали MS SQL Manager ;-)Это вечная проблема фреймворков - каждый разработчик фреймворка пытается сделать некое управление "гибкой структурой", при этом не желает или не может оценить степень необходимой пользователю гибкости.
В итоге получается некий велосипед, который для программиста уже не удобен, так как слишком сильно его ограничивает, а для пользователя еще не удобен, так как требует слишком глубокого понимания основ программирования.
Это даже удивительно как эта идея юзерами управления "гибкой структурой" живуча.
Я наблюдал чела с Пародоком Досовым, типа разработавшего универсальную БД. А все просто. Сделал формы юзерам колонки добавлять, а вообще если что можно в БЛОБы запихал и готово. На вопросы почему бы юзерам не юзать штатные средства для этого - все равно по ходу они теперь типа проектировщики, ниче убидетильного не пояснил. Как юзер буит формировкть сложные сводные отчеты тоже.
Мне только не понятна вера в то, что на западе все такие тупые, что придумали средсва для фреймворков, но не доперли, что можно налабать некое управление "гибкой структурой". Ждали тока наших поделкиных.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38272308
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvmИх (конечных пользователей акцесса) несколько подвидов.

Ну его презентовали для работы End Usersами. :-)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38272697
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulvvmИх (конечных пользователей акцесса) несколько подвидов.

Ну его презентовали для работы End Usersами. :-)
Угу, плюс дежурная команда VBA - программистов (на всякий случай).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38272849
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Максим НPSV100пропущено...

Лично я к этому проекту не имею никакого отношения. Вот чего желает ТС:
пропущено...

Именно всё это и имеется в этом проекте, в т.ч. как раз поверх Neo4j. Причём это не только некая альтернатива решениям на основе реляционных баз (включая и для EAV), но и, в целом, другой взгляд на разработку информационных систем (отчасти Акссессо-подобный). Я не в курсе, насколько продукт пригоден для использования (думаю, что не очень), но проект интересен, прежде всего, концептуально. Особенно привлекательны способы обработки данных, что можно взять себе на вооружение, причём не только в рамках какой-то NoSQL. Весьма рекомендую ознакомиться.

Спасибо, именно эти статьи и привели меня к мысле попробовать заюзать графовую базу для таких дел. К сам ому Animotron'у я еще не готов, а вот Neo4j, почему бы и нет.
Зафигачить EAV и радоваться жизни это не проблема, только вот как то надоело, интересно решить данную задачу подругому, с использованием более подходящих для этого инструментов (или выяснить для себя, что это не так), поэкспериментировать (тем более текущий проект позволяет пока).
Если кому будет интересно могу отписаться о своей попытке, когда будут результаты.

Ну, если нет обязательной привязки к SQL-DB и проект позволяет поэкспериментировать, то вполне есть смысл что-то пощупать. Рекомендую ещё глянуть на TinkerPop - проект вокруг графовых данных, там есть и свой DSL-язык, и аналог JDBC для графданных, и какой-то сервер и пр. Я с ним не разбирался, что-то подробнее не скажу. Насколько я понимаю, проект известен в соответствующих кругах, поэтому есть смысл что-то ещё поискать вокруг этого проекта. Там есть биндинги и для Neo4j, и для OrientDB (но с ней осторожней, раньше глючила и ломала базы, не в курсе как сейчас).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38272855
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н,

да все уже сто лет как пережёвано
http://www.compress.ru/article.aspx?id=11515

Максим Нвкратце: хранить экземпляры сущностей в одной таблице в формате xml, и делать к ним sql-запросы с использованием xpath
а вот это - адский ад. С тем же успехом все можно хранить в одном blob одной записи (жёсткая шутка).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38272856
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
удивительно, как люди постоянно (и с завидным упорством) умудряются изобретать велосипед.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38272887
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvМаксим Н,

да все уже сто лет как пережёвано
http://www.compress.ru/article.aspx?id=11515
...
В той статье показано, как можно сделать, и какая получится фигня, если сделать именно так.

Вопрос - как надо? Чтобы фигня не получилась.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273026
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvМаксим Н,

да все уже сто лет как пережёвано
http://www.compress.ru/article.aspx?id=11515

Максим Нвкратце: хранить экземпляры сущностей в одной таблице в формате xml, и делать к ним sql-запросы с использованием xpath
а вот это - адский ад. С тем же успехом все можно хранить в одном blob одной записи (жёсткая шутка).

Дык это статье 12 лет ....
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273105
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НДык это статье 12 лет ....
ну и что изменилось за 12 лет? я сам делал "хранилище объектов" еще в 1993 году, на таблицах Paradox.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273213
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvМаксим НДык это статье 12 лет ....
ну и что изменилось за 12 лет? я сам делал "хранилище объектов" еще в 1993 году, на таблицах Paradox.

Прогресс не стоит на месте, расцветают kv-базы, документоориентированные, графовые и др. (не мне вам рассказывать). Вот я и подумал, что наверняка есть какой-либо другой способ решения данной проблемы.
Про плюсы и минусы EAV все прекрасно знают. А вот про минусы использования графовых баз (или других решений), что из этого вообще может получится, я пока информации найти не могу. Видимо придется пробовать самому.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273318
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НПрогресс не стоит на месте, расцветают kv-базы, документоориентированные, графовые и др. (не мне вам рассказывать).

Одно дело расцветать, другое расцвести.

Максим Н А вот про минусы использования графовых баз (или других решений), ....
Это не сетевые часом? Оные, мягко говоря, относятся к прогрессу более раннему чем 12 лет. Это вообще дореляционная эпоха.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273363
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoМаксим Н А вот про минусы использования графовых баз (или других решений), ....
Это не сетевые часом? Оные, мягко говоря, относятся к прогрессу более раннему чем 12 лет. Это вообще дореляционная эпоха.

Да, точнее их разновидность. Не в возрасте дело, а в том что помимо реляционки есть другие замечательные МД, вот и интересуюсь как с помощью них можно (и можно ли вообще) более естественно решить поднятую здесь задачу.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273457
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НПрогресс не стоит на месте, расцветают kv-базы, документоориентированные, графовые и др. (не мне вам рассказывать). Вот я и подумал, что наверняка есть какой-либо другой способ решения данной проблемы.
Про плюсы и минусы EAV все прекрасно знают
все так, но вот мне кажется, что пустое обсуждение этого вопроса на трех страницах, плюс, наличие в википедии означенной темы только на одном языке, явно намекает на степень популярности этой темы.
http://en.wikipedia.org/wiki/Entity–attribute–value_model

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

p.s. если я правильно помню, системы типа EAV показывают производительность, обратно пропорциональную количеству объектов и их экземпляров в системе. По идее, 1С 8 как раз по такой схеме сделана.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273458
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да, еще добавлю, что в последнее время я вижу разве что в отдельных CRM возможность создания дополнительных атрибутов к уже имеющимся сущностям. И то с этим есть определенные проблемы (у пользователей, опять же).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273507
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvМаксим НПрогресс не стоит на месте, расцветают kv-базы, документоориентированные, графовые и др. (не мне вам рассказывать). Вот я и подумал, что наверняка есть какой-либо другой способ решения данной проблемы.
Про плюсы и минусы EAV все прекрасно знают
все так, но вот мне кажется, что пустое обсуждение этого вопроса на трех страницах, плюс, наличие в википедии означенной темы только на одном языке, явно намекает на степень популярности этой темы.
http://en.wikipedia.org/wiki/Entity–attribute–value_model

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

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

Может глупость скажу, но все же: а как же тот самый Эксель, где пользователь сам описывает и заполняет таблчики, делает выборки над ними, имитирует связи между ними, расчеты и т.д.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273509
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvда, еще добавлю, что в последнее время я вижу разве что в отдельных CRM возможность создания дополнительных атрибутов к уже имеющимся сущностям. И то с этим есть определенные проблемы (у пользователей, опять же).

Особенно в магазинах и всяких каталогах это популярная тема. Как в Magento например, которые слезают с EAV - http://dimitrigatowski.com/2011/06/19/magento-2-preview/
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273532
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н,

ну когда же ты уже начнешь кодить?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38273635
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НМожет глупость скажу, но все же: а как же тот самый Эксель, где пользователь сам описывает и заполняет таблчики, делает выборки над ними, имитирует связи между ними, расчеты и т.д.
Даже excel имеет слишком высокую для большинства пользователей сложность. Далеко не все осваивают создание формул, а уж про аналитику и говорить не стоит. Если же к нему навернуть еще и некое "описание модели данных", то это станет инструментом для совсем немногих (тот самый один из тысячи, о котором писал kdv). Но хитрость как раз в том, что для этих "избранных" уже существуют гораздо более удобные и функциональные инструменты.
В общем, прежде чем создавать новый конструктор надо четко понять целевую аудиторию. Если это будут программисты, то подходы используются одни, для менеджеров - совсем другие, а для бухгалтеров - третьи. А если использовать программистские подходы в инструменте для бухгалтера, то ни программист, ни бухгалтер нормально им пользоваться не сможет.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38274016
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НДа, точнее их разновидность. Не в возрасте дело, а в том что помимо реляционки есть другие замечательные МД, вот и интересуюсь как с помощью них можно (и можно ли вообще) более естественно решить поднятую здесь задачу.

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

Пысы
Впрочем, и на лошади может быть более естественно ездить чем на авто.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38274155
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор.s. если я правильно помню, системы типа EAV показывают производительность, обратно пропорциональную количеству объектов и их экземпляров в системе.
точно нет.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38274484
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавтор.s. если я правильно помню, системы типа EAV показывают производительность, обратно пропорциональную количеству объектов и их экземпляров в системе.
точно нет.
Зависит от того, что нужно получить и "как оно делается".

Время выполнения обычного select к табличке без индексов тоже будет тем дольше, чем больше записей.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38274747
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЗависит от того, что нужно получить и "как оно делается".
ну это к EAV отношения уже не имеет.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38274952
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowточно нет.
точно да, по двум причинам:
1. если в обычной схеме таблица=объект атрибуты (столбцы) расположены горизонтально, и всегда есть доступ ко всем "атрибутам", то в объектной схеме атрибуты расположены вертикально. Понятно, что по затратам дискового места объектная схема не сильно больше табличной, но тут вступает в действие пункт 2:

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

например, еще до построения объектной схемы на РСУБД я строил такую на ДИАМС (Mumps, или глобали Cache, если угодно). Скорость поиска и выборки данных объектов была высокой за счет дублирования данных (избыточности) и самой иерархической схемы. То же самое на реляционке построить можно, но с теми же затратами, но уже без преимуществ иерархической системы.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275194
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор2. запросы для вытаскивания объектов, атрибутов и их значений обычно сложнее, чем запросы к "горизонтальным атрибутам". А в результате, даже при наличии индексов, стоимость выборки одних и тех же данных может сильно отличаться как по процессорным, так и дисковым ресурсам.
эм. признавайся, что ты сделал с настоящим kdv!
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275199
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
запросов там ровно полтора.
select * from meta_value where object_id = ?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275205
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
причем что самое смешное:
1) из за маленького размера строки самой meta_value, по диску и памяти мы еще и выигрываем.
2) очень просто делаются запросы по набору атрибутов
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275223
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrow,

что это вы, тётенька, такое рассказываете? :)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275292
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowпричем что самое смешное:
1) из за маленького размера строки самой meta_value, по диску и памяти мы еще и выигрываем.
2) очень просто делаются запросы по набору атрибутова по двум атрибутам? т.е. допустим если мне надо искать нечто допустим по дате и номеру, то когда они в одной таблице я делаю индекс из двух полей, а с ЕАV как?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275306
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperа с ЕАV как?
Делаешь два индекса из одного поля.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275319
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrow,

если бы с объектной моделью было все зашибись, то сейчас бы все на ней только и сидели.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275352
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvScareCrow,

если бы с объектной моделью было все зашибись, то сейчас бы все на ней только и сидели.

там одна пробдема, для двузвенки она не подходит. средний слой полюбому нужен. там где он есть - там все и сидят.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275386
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrow...для двузвенки она не подходит. средний слой полюбому нужен...
Это чего так?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275406
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а почему нет?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275412
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чего такого умеет третье звено с чем не справится второе?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275542
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Максим НПрогресс не стоит на месте, расцветают kv-базы, документоориентированные, графовые и др. (не мне вам рассказывать). Вот я и подумал, что наверняка есть какой-либо другой способ решения данной проблемы.
Про плюсы и минусы EAV все прекрасно знают. А вот про минусы использования графовых баз (или других решений), что из этого вообще может получится, я пока информации найти не могу. Видимо придется пробовать самому.
...
Может глупость скажу, но все же: а как же тот самый Эксель, где пользователь сам описывает и заполняет таблчики, делает выборки над ними, имитирует связи между ними, расчеты и т.д.

Bogdanov AndreyДаже excel имеет слишком высокую для большинства пользователей сложность. Далеко не все осваивают создание формул, а уж про аналитику и говорить не стоит. Если же к нему навернуть еще и некое "описание модели данных", то это станет инструментом для совсем немногих (тот самый один из тысячи, о котором писал kdv). Но хитрость как раз в том, что для этих "избранных" уже существуют гораздо более удобные и функциональные инструменты.
В общем, прежде чем создавать новый конструктор надо четко понять целевую аудиторию. Если это будут программисты, то подходы используются одни, для менеджеров - совсем другие, а для бухгалтеров - третьи. А если использовать программистские подходы в инструменте для бухгалтера, то ни программист, ни бухгалтер нормально им пользоваться не сможет.


Максим, если речь идёт о создании некоего универсального конструктора, современного продвинутого экселя, причём в рамках какой-то своей тренировки, то рекомендую оценить такой подход.

Может есть смысл сделать продвинутые Mind map . Есть куча десктопных инструментов для их создания, и куча вэбсайтов для этого (возможно есть и готовые фреймворки) и т.д. Но вот продвинутых, для полноценного моделирования, что-то не видно. Возможно, они кому-то реально потребуются. Вот, к примеру, здесь можно посмотреть примеры того, что эти диаграммы вполне могут быть интегрированы и с другими элементами: с графиками, таблицами и пр. Рекомендую подкрепить эти карты памяти взаимосвязанными хотя бы таблицами, вики-текстом (причём с метаинформацией, т.е. понимать вики-текст как структурный документ, с разделами и идентификаторами и пр.), ну может и графиками и пр. Естественно, оперировать нужно не просто текстом (как обычно в диаграммах), а полноценными "эксель-данными". Для программистов можно дать возможность оперировать языком программирования. В проекте Анимотрон есть пример пролого-подобного языка. Вот здесь (или здесь презентация) - ещё один пример пролого-подобного - это инструмент для анализа кода, где тоже имеется понятие реляционных отношений. В проекте TinkerPop есть ещё один пример языка над графовыми данными.
Для рядовых пользователей можно дать визуальный инструмент для алгоритмов (или в дополнение к языку "формул"), в виде блок-схем или подобное, или что-то по мотивам Sctratch, например, взять гугловский Blockly .

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


По поводу графовых баз и прочего NoSql. Я не эксперт в них, и у меня нет практического опыта их применения на серьёзном проекте (но кое-какой неуспешный опыт есть). У меня к ним сформировалось предостережение. Во-первых, нужно понимать риски и проблемы с надёжностью данных. Не забывать, что они специфично реализованы, якобы решая проблемы традиционных SQL-баз (повышая производительность, где может не быть журналов, транзакций, реализуют горизонтальное масштабирование, делают кэш базы в памяти с дампами на диск и т.д. и т.п.), и эта специфичность может вылезти боком иногда. Ну, например, манипулирование через memory map даёт выше производительность, но при глюках софта случайная запись в соответствующую область памяти кроме краха процесса или потока может дать и запись мусора в БД. Или если СУБД всю базу отражает в памяти, то можно эту память легко всю выжрать.
Во-вторых, нужно оценивать способы работы с данными на низком уровне. Например, если СУБД не предусматривает какое-то создание версий данных где-то рядом с исходной записью, то после модификаций данных или/и удаления (т.е. начинаются попытки использования СУБД как SQL-БД) картина уже не такая радостная (а по первой имеется бешеная скорость добавления даже огромного количества данных, мгновенные выборки и пр.). Или платой за schema less может послужить то, что внутри каждой записи имеются имена полей, кроме самих данных, и в какой-нибудь mongo это запросто может заставить создавать имена полей из пары символов.

Короче говоря, здесь могут реальные эксперты привести кучу проблем, так и успешное соответствующее применение. Единственно, что раздражает, это когда "эксперты" бросаются громкими словами, типа посмотрите на фейсбуки с твитерами, как-будто это их личный опыт и успех. В тоже время забывают про тот же скайп, который мучается на постгрессе, имея кучу распределенных баз (они, кстати, вроде как где-то делились своими разработками и расширениями для постгресса, включая, если не ошибаюсь, возможность выполнения распределенных sql-запросов).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275622
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvScareCrow,
если бы с объектной моделью было все зашибись, то сейчас бы все на ней только и сидели.
Со Smaltalk'ом всё "зашибись". Но есть ещё такие важные факторы, как зависимость от выбранного пути (например, раз что-либо выучив, потом с него не слезают) и мода.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38275872
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaСо Smaltalk'ом всё "зашибись". Но есть ещё такие важные факторы, как зависимость от выбранного пути (например, раз что-либо выучив, потом с него не слезают) и мода.
Но путь выбирают все новые и новые лица с нуля. Мода - тоже как-то должна была бы пройти по времени, например, на РМД. Все таки прошлый век. Но что-то удерживает не только ее, но даже ЕАV (выернутый на изнанку РМД), который существет, скорее всего, только благодаря существованию РМД.
Т.е. нельязя исключать существование и других факторов. Типа Со Smaltalk'ом всё "зашибись", но не сильно "зашибись" как например, с РМД в БД. Судите, сами: РМД лабают в соседней ветки топике красотки, возможно, блондинки, а на Smaltalk не любой батан нарулит, что-то стоящее.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38276410
Andrey Sribnyak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovSergSuperа с ЕАV как?
Делаешь два индекса из одного поля.


asc and desc
Почему нет? :)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38276461
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoНо путь выбирают все новые и новые лица с нуля.
Ага, щаззз. Ни с какого ни с нуля. Дорожка протоптана до состояния асфальта, уклонение чревато огромным риском.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38277970
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Максим Н

Почитал я ссылку на хабру, почитал топик, аж запечалился .

Посмотрите видео, может это именно то, что Вам нужно?
YouTube Video
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38278256
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ только одно могу сказать по этому поводу - бытие определяет сознание. :)

Без дополнительных пояснений это может выглядеть как обращение к неким идеям марксистко-ленинской пропаганды. Что если и могло бы усилить позиции "объектной модели" в определенных странах, то, скорее всего, теперь уже в отдаленном прошлом. Ну сегодя разве на Кубе или в Пхеньяне.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38278312
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нет.
Это я обобщил знакомыми словами мысль Дейкстра "Используемые инструменты оказывают глубокое (и окольное!) влияние на наши способ мышления, и, следовательно, на нашей способности к мышлению".

Оригинал здесь . Всячески советуй. Местами обидно, но верно.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38278317
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А все дополнительные пояснения есть в видео.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38278871
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneА все дополнительные пояснения есть в видео.
Докатились.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279001
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneА все дополнительные пояснения есть в видео.
Ну не все же любители подобного рода видио, когда рядом есть "Уральские пельмени". Поэтому как бы такие дополнительные пояснения, возможно, следует отнести к чрезмерно громоздкими, чтобы с ними можно было ознакомиться.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279012
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneА все дополнительные пояснения есть в видео.А навык связного изложения в письменном виде - стал утраченным искусством?
Или превратился в чёрную магию?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279083
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovА навык связного изложения в письменном виде - стал утраченным искусством?
Или превратился в чёрную магию? Ссылка из профиля U-gene на pdf .
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279098
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoU-geneА все дополнительные пояснения есть в видео.
Ну не все же любители подобного рода видио, когда рядом есть "Уральские пельмени". Поэтому как бы такие дополнительные пояснения, возможно, следует отнести к чрезмерно громоздкими, чтобы с ними можно было ознакомиться. Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. Ситуация для меня обычная, привычная и понятная. Поэтому я сразу даю видео, где показано как эта СУБД работает и объяснены основные принципы как можно объединять ОО и РМ, так, что бы они друг другу не мешали, и даже помогали. Тема запутанная, у людей в голове каша, двумя словами от этой каши не избавишь, а на словесные баталии мы потратим больше времени, чем 36 минут (длительность видео). Я даже не настаиваю: хотите - смотрите, не хотите - не смотрите.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279112
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneА все дополнительные пояснения есть в видео.А навык связного изложения в письменном виде - стал утраченным искусством?
Или превратился в чёрную магию? Да я пишу уж 13 лет как. :) В том числе здесь. По теме ближе всего наверное это .
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279135
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
servit... и это тоже.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279148
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneДа я пишу уж 13 лет как. :) В том числе здесь. По теме ближе всего наверное это .Есть одна проблема - нет реализации.
Как говаривал один из участников истории "Редкая профессия" - не летает.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279165
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneДа я пишу уж 13 лет как. :) В том числе здесь. По теме ближе всего наверное это .Есть одна проблема - нет реализации. А в видео что? Я же не на пальцах объясняю.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279207
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneА в видео что? Я же не на пальцах объясняю.Именно, что на пальцах.
Очередные подтяжки для тех, кто не хочет или не может освоить декомпозицию.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279229
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЕсли я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп.
Здесь подробно рассматривались все аспекты
http://www.sql.ru/forum/973198/db-specific-orm
Что значит "полностью соединяет"?
Замена термина "маппинг" термином "трансляция" не может избавить от архитектуры "модль верхнего уровня+маппинг+РМД"
U-gene...Поэтому я сразу даю видео, где показано как эта СУБД работает и объяснены основные принципы как можно объединять ОО и РМ, так, что бы они друг другу не мешали, и даже помогали.
В известной статье, на которую указал servit, проблемы маппинга рассматриваются вскользь и весьма туманно:

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

Весьма не формально - "тесно связаны"))
И в презентации нет разъяснений. Какая МД используется на верхнем уровне? Если это МД, то маппинг должен поддерживаться по всем трем аспектам: структура, ОЦ, манипулирование. Как это осуществляется?
Можно только предположить, что в качестве МД верхнего уровня используется либо М4, либо М5
13577413
U-geneТема запутанная, у людей в голове каша, двумя словами от этой каши не избавишь, а на словесные баталии мы потратим больше времени, чем 36 минут (длительность видео). Я даже не настаиваю: хотите - смотрите, не хотите - не смотрите.
Потратил 108 минут. Для начала))...
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279291
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneBasil A. Sidorovпропущено...
Есть одна проблема - нет реализации. А в видео что? Я же не на пальцах объясняю.Именно, что на пальцах.
Очередные подтяжки для тех, кто не хочет или не может освоить декомпозицию.Я не понял, что тогда подразумевается под "отсутствием реализации", как из этого следуют "подтяжки для тех, кто не хочет или не может освоить декомпозицию", и что имеется в виду под "освоить декомпозицию"
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279321
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятина, (о! наши подошли :) )
я давно Вам говорил - я не хочу думать о моделях верхнего уровня. Я не думаю о сущностях и связях . Есть СУБД (система), для ее управления используется язык, в нём есть языковые конструкции, позволяющие описывать те или иные структуры данных и даже классы (т.е. структуры данных и применимые к ним методы)

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

И термин маппинг я именно по этой причине вопинимаь не хочу. Речь идет о трансляции , т.е. о механическом переписывании входных команд в выходные на основании данных о структуре, сохраненных в таблице имен.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279325
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. .
Ну , к примеру, ОРСУБД тоже "соединяет" ОО и РМ. Ну и существуют типа ОРСУБД. Т.е. самом по себе "соединяет ОО и РМ" вроде как ничего не меняет в топике: обе структурированные МД (типа "жесткие структуры").
А ТС вроде хотел типа "гибкой структурой".
Скорее всего, в литературе по БД речь идет о полуструктурированных, слабоструктурированных МД. К ним ни ОО и РМ и, скорее всего, их "соединения" не относятся.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279336
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoU-gene Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. .
Ну , к примеру, ОРСУБД тоже "соединяет" ОО и РМ. Ну и существуют типа ОРСУБД. Т.е. самом по себе "соединяет ОО и РМ" вроде как ничего не меняет в топике: обе структурированные МД (типа "жесткие структуры").
А ТС вроде хотел типа "гибкой структурой".
Скорее всего, в литературе по БД речь идет о полуструктурированных, слабоструктурированных МД. К ним ни ОО и РМ и, скорее всего, их "соединения" не относятся.
ТС в первом посте дал более четкое описание, что имеется в виду под "гибкой структурой". Судя по этому описанию, имелось в виду "как согнул, так и будет, самое главное, что бы гнулась в любую сторону", хотя я могу и ошибаться.
Что касается OРСУБД - там объекты только в названии. UTD до полноценных классов никак не тянут. а попытка натянуть их на таблицы нарушает РМ даже в формальной части.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279347
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneТС в первом посте дал более четкое описание, что имеется в виду под "гибкой структурой". Судя по этому описанию, имелось в виду "как согнул, так и будет, самое главное, что бы гнулась в любую сторону", хотя я могу и ошибаться.
Так и есть.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279362
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneТС в первом посте дал более четкое описание, что имеется в виду под "гибкой структурой".
Судя по этому описанию, имелось в виду "как согнул, так и будет, самое главное, что бы гнулась в любую сторону", хотя я могу и ошибаться.

Не знаю что тут четкого. Но, скорее всего, речь идет об избитой идее модификации структуры конечным юзером. И в ОО и в РМ это означает изменение МД. И это обычно требует известной квалификации и отвественности проектировщика. А если юзер буит делать, то, есть риски, что старые запросы могут мягко говоря показывать совсем не то, что должны бы. А новые писать геморно будет и опытному базисту.

То что описал ТС хоть и не четко, но типа в сторону полуструктурированных. Например, XML СУБД. Т.е. они тоже могут не подойти, но они, скорее всего, ближе, чем структурированные.

U-geneЧто касается OРСУБД - там объекты только в названии. UTD до полноценных классов никак не тянут. а попытка натянуть их на таблицы нарушает РМ даже в формальной части.
Это детали.
"Обектно" не означает существование полноценности классов. А нарушение базовой РМ при ее расширениях неизбежны. Иначе в чем расширение, если все осталось как было.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279451
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoЭто детали.
"Обектно" не означает существование полноценности классов. А нарушение базовой РМ при ее расширениях неизбежны. Иначе в чем расширение, если все осталось как было.
1) Это не детали.
2) Насчет расширений.
Идея как раз в том, что вообще не надо ничего расширять. У меня следующая аналогия. Есть квадрат и есть круг. Требуется найти что то, что было бы и круглым и квадратным. Все пытаются как то "расширить" одну фигуру до другой и изобразить то закругленный квадрат, то оквадраченный круг (...не знаю, что это такое, сами попробуйте представить). Моя система в этой аналогии - цилиндр. Одна проекция - правильный круг, другая (ортогональная) - правильный квадрат, а для того, что бы соотнести проекции используются имена, общие для обеих проекций.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279453
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoНо, скорее всего, речь идет об избитой идее модификации структуры конечным юзером. .... И это обычно требует известной квалификации и отвественности проектировщика. А если юзер буит делать, то, есть риски, что старые запросы могут мягко говоря показывать совсем не то, что должны бы. А новые писать геморно будет и опытному базисту.
Причем здесь пользователь? А я? Я не пользователь, но с С на С++ и дальше на С# (или Java) сам по своей воле переползал (вместе со всем миром). Потому что мне, как разработчику, тоже удобнее думать в ОО терминах.

Думайте как хотите. Дать пользователю или не себе оставить - вообще не моя проблема. Было бы что.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279486
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну эта, я тут пока жу как я это себе представляю, по поводу графов (см. картинку).
Атрибуты пока не зарисовал и думаю и так понятно, чтобы не нагромождать картинку.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279488
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тут на всякий случай Cypher-код создания базы (той что на картинке):


// START n = node(*)
// MATCH n-[r?]-()
// DELETE n, r;


//Create root entity
CREATE (a {name : 'Base Abstract Entity'})
RETURN a;

//Create entity
CREATE (a {name : 'Vehicle'})
RETURN a;

CREATE (a {name : 'Car'})
RETURN a;

CREATE (a {name : 'Plane'})
RETURN a;



START left=node(*), right=node(*)
WHERE (left.name="Base Abstract Entity" and right.name="Vehicle")
CREATE UNIQUE left-[r:ENT_TYPE_INH]->right
RETURN left, right;


//
START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Car")
CREATE UNIQUE left-[r:ENT_TYPE_INH]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Plane")
CREATE UNIQUE left-[r:ENT_TYPE_INH]->right
RETURN left, right;







//Create vehicle attributes types
CREATE (a {name : 'Speed'})
RETURN a;

CREATE (a {name : 'Power'})
RETURN a;

CREATE (a {name : 'Size'})
RETURN a;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Speed")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Size")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Power")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;




//Create car attributes types
CREATE (a {name : 'WheelsCount'})
RETURN a;

START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="WheelsCount")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;



//Create plain attributes types
CREATE (a {name : 'WingsCount'})
RETURN a;

START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="WingsCount")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;





//Create cars objects
CREATE (a {name : 'Ferrary F50'})
RETURN a;

CREATE (a {name : 'BMV'})
RETURN a;

CREATE (a {name : 'VAZ'})
RETURN a;


START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="Ferrary F50")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="BMV")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="VAZ")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;







//Create planes objects
CREATE (a {name : 'Boeng'})
RETURN a;

CREATE (a {name : 'Aerobus'})
RETURN a;

CREATE (a {name : 'SuperJet'})
RETURN a;


START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="Boeng")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="Aerobus")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="SuperJet")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279493
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene ...я давно Вам говорил - я не хочу думать о [b]моделях верхнего уровня. Я не думаю о сущностях и связях . Есть СУБД (система), для ее управления используется язык, в нём есть языковые конструкции, позволяющие описывать те или иные структуры данных и даже классы (т.е. структуры данных и применимые к ним методы)
Еще раз:
"Исходя из особенностей реляционной машины, процесс трансляции описывается схемой "имена-->(трансляция)-->имена", то есть, имена структур памяти реляционной машины формируются из имен, вводимых при описании объектных структур . При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины ."
На стороне "реляционной машины" есть логическая МД. Вы утверждаете, что МД верхнего уровня может быть любая. Тогда нужно ясно показать, как любая МД верхнего уровня может использоваться в Вашей, не ориентированной ни на какую конкретную модель СУБД???
U-geneЯ Вашу M-классификацию давно видел. Сейчас еще раз посмотрел. С учетом того, что я предлагаю эволюцию РСУБД (этот момент в видео дан "на пальцах") и таблицы никуда не денутся, а мои классы могут использоваться как домены этих таблиц, то в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте. Впрочем я на этом настаивать не буду и спорить не хочу.
Не нужно настаивать и спорить. Нужно просто взять, например, М2 и показать на примере.
Но, пока, очень важный момент: Вы, все-таки, строго по Дейту делаете - подтвердите еще раз, что класс неизвестной, пока, МД верхнего уровня - это ДОМЕН РМД . То есть, Фамилия Человека, например, - это у Вас класс. Так? А Человек тогда что?
U-geneИ термин маппинг я именно по этой причине воспринимать не хочу. Речь идет о трансляции , т.е. о механическом переписывании входных команд в выходные на основании данных о структуре, сохраненных в таблице имен.
И еще раз, для верности:
"... При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины ."
Покажите на примере, пожалуйста.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279854
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н,

Субд тут ни при чем, на базе любой можно сделать такое приложение. Дело в том как делать, а не в субд.

Как делать — читай про EAV.

Но кстати есть субд и специально на это ориентированные, RDF storage например.
Можешь также прочитать про rdf и sparql.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279982
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-genevadiminfoпропущено...

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

Единственный вопрос.

Какая связь между вашей RxO и текущей темой: "Хранение данных с гибкой структурой и запросы к ним"?
Никакой.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38279999
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneИдея как раз в том, что вообще не надо ничего расширять. .
Если добавляетсся ОО, то с одной расширение как бы есть, так как ничего из ОО (классов, методов...) в РМ нет. С другой, если расширеня нет, то это просто то что и было: ниче нового.

U-geneПричем здесь пользователь?
.
Для него пользователя здесь "гибкая структура" у ТС, наколько я понял. А иначе "негибкой структуры" бы как и везде хватило: проектировщик то не буит к нему кажный день ходить структуры гнуть.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38280034
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoНо, скорее всего, речь идет об избитой идее модификации структуры конечным юзером. И в ОО и в РМ это означает изменение МД. И это обычно требует известной квалификации и отвественности проектировщика. А если юзер буит делать, то, есть риски, что старые запросы могут мягко говоря показывать совсем не то, что должны бы. А новые писать геморно будет и опытному базисту.


1.не МД, метаинформации для создания модели предметной области
2.изменение модели пользователем - архиважная фигня
3.рисков никаких не должно быть
4.все должно быть структурировано до безобразия

для того что бы 2-4 работало, ОО и РМД маловато будет (С РМД то фиг с ним, можно выкрутится, а ОО маловато)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38280265
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene,

Спасибо за презентацию проекта. Концептуально интересно, но не понятны ряд ключевых моментов. Отсюда вопросы:

- Насколько реально ликвидированы проблемы состыковки объектных данных и данных в РМ ?

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

Или же это какой-то Акцесс/фокспро или как проект Animotron, здесь выше давали ссылки на него. Т.е. это некая пусть виртуальная машина, которая интегрировано предоставляет весь цикл разработки и сама исполняет закладываемый широкий функционал. Ну, например, имеется ли взаимодействующий с данными слой презентации, где в скрипте можно задать "create form ..." и где-то выдать "select <что-то> into <такая-то форма> ", в результате на экран можно вывести форму или сервер сформирует HTML/javascript/json- и пр. ответ.

Или есть ли какая-то технология выше над моделью хранимых данных. К примеру, есть ли дополнительные операторы в языке для взаимосвязанного описания классов, которыми уже оперируют на клиентской стороне, затем при "исполнении" кроме sql-запросов непосредственно для СУБД будут ещё генерироваться java/C# и пр. классы. Т.е. что-то вроде "M моделирования" от майкрософт.

Одним словом, непонятно как использовать продукт. Или это только прототип возможного языка на "сервере" ?


- Насколько реально возможна трансформация жизненно необходимого исходного SQL ?

Есть ли возможность оперировать, скажем, рекурсивными запросами. Или возможны ли какие-то инварианты. Ну, например, если я применю одно объектное выражение, которое заставит систему генерировать sql с подзапросами, а если по-другому - получим соединение таблиц (это, конечно, всё условно, я понимаю, что об оптимизации заботятся изначально). Или есть ли какая-то лазейка для прямой спасительной sql-инъекции, если система чего-то не может.
Всё таки, подобные абстракции над какой-то Key-Value базой, когда за рамками контролирующего прикладного ядра лучше и не лазить напрямую в БД - это одно. А если система уже поверх мощного SQL заставит вести не малую часть разработки за своим бортом - это другое.

- На сколько развит сам язык моделирования и запросов ?

Как я понимаю, делается попытка быть поближе к SQL, но с ООП-мотивами. Язык SQL хоть и декларативный, но очень прямолинеен. В нём элементарно задалбывает вручную оперировать, например, большими списками столбцов и связанных с ними данных. Или слабый потенциал для инвариантности вынуждает формировать в коде несколько вариантов SQL-оператора, который за собой тянет и варианты окружающего кода. Есть ли какие-то технологии, облегчающие жизнь. Например, как-то так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
-- ниже "a", "b", "c" обычные переменные:
a := 23;
b := 345.678;
c := "привет ...";

-- ниже кортеж или объект с именованными полями (a, b, c), где оператор "..."
-- указывает на действия по умолчанию (т.е. b = b, c = c)
rec := (a = a, ...);

-- обновляем класс
UPDATE <класс>[<какое-то where>] SET rec; 




- Насколько развита ООП-технология как такова ?

Например, есть ли понятие явных конструкторов, с их наследованием. Возможны ли какие-то механизмы типа дженериков или какого-то параметрического полиморфизма. Есть ли механизм "виртуальных вызовов". Например, пусть я сформирую выборку из объектов разных классов (подклассов) (пока даже не знаю как, возможно, через какой-то "union"), и укажу выполнить метод как-то так: "FOR <выборка> EXEC <метод>", и соответственно я должен ожидать то, что для каждого объекта будет "выполнен" корректный метод нужного класса. И пр.


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

Всё таки, ООП само по себе имеет немало допущений и неоднозначности, и проблем, для проектирования, моделирования, да и в реализации. От того постоянны разговоры как наследовать прямоугольники с квадратами, "дверь в комнату" сама открывается или её открывает "входящий". Множественное наследование даёт технические проблемы, и, в целом, наследование с понятием субтипа иногда (или не редко) вынуждает приводить реальный тип объектов к верхнему базовому типу, с которым ничего толком и не сделаешь, без вынужденного небезопасного последующего приведения типа. Без относительно строгой типизации вполне можно слонов с мухами складывать и т.д. и т.п. Хотя, собственно, притащить проблемы ОПП в проект можно настолько, насколько эмулируется это ООП.

Спасибо.

P.S. Если подобные вопросы постоянно задают, м.б. есть смысл дать какую-то ссылку, где всё уже по полочкам разложено.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38280708
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ не понял, что тогда подразумевается под "отсутствием реализации", как из этого следуют "подтяжки для тех, кто не хочет или не может освоить декомпозицию", и что имеется в виду под "освоить декомпозицию"Своей презентацией вы продемонстировали:
а) универсальность реляционных СУБД
б) практичность реляционных СУБД
Зачем прикручивать к универсальной и практичной вещи некую надстройку, которых уже и так вагончик - лично мне осталось непонятным.
Что касается декомпозици ...
В основе и ORM-ов и вашего RxO лежит концептуальный прокол - представление о том, что объекты определяют структуру данных.
Отсюда и автогенерация схем и автоматическое построение запросов и аннотации для указания связей и т.п.
На самом же деле приложение "видит" данные через призму DML, а отображение этих самых DM на объекты - вторично, т.к. сильно зависит от семантики.
Нужно просто принять как факт, что реляционная алгебра - проста. И научиться решать реляционные задачи точно так же, как в школе решались квадратные уравнения.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38280996
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovU-geneЯ не понял, что тогда подразумевается под "отсутствием реализации", как из этого следуют "подтяжки для тех, кто не хочет или не может освоить декомпозицию", и что имеется в виду под "освоить декомпозицию"Своей презентацией вы продемонстировали:
а) универсальность реляционных СУБД
б) практичность реляционных СУБД
Зачем прикручивать к универсальной и практичной вещи некую надстройку, которых уже и так вагончик - лично мне осталось непонятным.
Что касается декомпозици ...

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

Сегодня как раз был разговор на подобную тему в другом форуме, приведу цитату оттуда:
Илья ЕрмаковКстати, возможно, серьёзное заблуждение в том, что "устаканить" и качественно построить уровень системного проектирования, моделирования и т.п. можно полностью изолированно от уровня реализации (наплевав на то, какие технологии лежат ниже, на уровне программной реализации).
Наконец-то все в ИТ усвоили идею абстрагирования, изоляции нижележащих особенностей... Но уверовали в другую крайность - "всё равно, на чём реализовывать, главное спроектировать и правильно поставить процесс".

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

Подход, когда аналитики и архитекторы должны непосредственным образом участвовать и в работе команды программистов (сами огребать все проблемы в реализации того, что они наанализировали и напроектировали), пропагандирует, кстати, Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38281035
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100 Имхо, вполне оправданы попытки привести технологии реализации в гармоничный вид. Я имею в виду то, что сама по себе гармония важна. Вот во времена клиперов с фокспро была отличная гармония, реляционная модель и внутри БД, и она же в "клиенте".

Это не была гармония. Это было что-то с чем-то.
Но за не имением лучшего, приходилось использовать.
Когда появились достаточно производительные SQL-сервера по разумной цене, так все СУРБД на основе xBase (д и других процедурных ЯП) тут же ушли "в тень".

PSV100 Как только начали появляться классы с объектами, на ту же фокспро стало противно смотреть.

Если что, то в FoxPro давно есть классы и объекты.
Даже в Clipper 5.1 уже были классы объекты.
Не в них дело, а в доступных SQL-серверах.

PSV100Такова уже историческая особенность мэйнстрима, что ему навязали ООП как серебряную пулю, преподнесли не только как продвинутый препроцессор для ассемблера, но и как средство уже системного моделирования, но для чего ООП, фактически, не пригодно.

Ну не думаю, что такое резкое высказывание "... средство уже системного моделирования, но для чего ООП, фактически, не пригодно..." верно.
Системное моделирование как раз просто и прозрачно реализуется в ООП.
Просто попытка в ООП ЯП "втиснуть" SQL в виде ORM, приводит к проблемам, когда возможностей SQL не хватает.
Фактически нужно написать свой "SQL", только не SQL.
Для простых вещей это можно, для сложных нет.

Поэтому создание "гибкой структуры" - миф.
Гибкая структура уже есть - SQL-сервер ;-)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38281671
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mad_nazgulКогда появились достаточно производительные SQL-сервера по разумной цене, так все СУРБД на основе xBase (д и других процедурных ЯП) тут же ушли "в тень".
...
Если что, то в FoxPro давно есть классы и объекты.
Даже в Clipper 5.1 уже были классы объекты.
Не в них дело, а в доступных SQL-серверах.
...

У xBase, конечно, хватало тараканов, но как раз без их классов и было проще делать свои абстракции. А при возможности xBase приспособили бы для серверов, но их ключевой индексно-последовательный метод работы с данными в принципе не позволяет реализовать адекватную работу интенсивных параллельных транзакций (или пользователей). Это как раз пример того, что "материал" не может обеспечить требуемую технологию производства.

mad_nazgulНу не думаю, что такое резкое высказывание "... средство уже системного моделирования, но для чего ООП, фактически, не пригодно..." верно.
Системное моделирование как раз просто и прозрачно реализуется в ООП.

У меня свой опыт и несколько иное мнение. Недавно в соседней теме форума возникал подобный офтоп, поделюсь ссылкой .

mad_nazgulПросто попытка в ООП ЯП "втиснуть" SQL в виде ORM, приводит к проблемам, когда возможностей SQL не хватает.
Фактически нужно написать свой "SQL", только не SQL.
Для простых вещей это можно, для сложных нет.

Я несколько лет назад встретил проект на Кложуре, для меня это образцово показательные выступления. Здесь выше давали ссылку на соседнюю тему DB specific ORM , что заставило опять поискать этот проект в инете, не нашёл (и названия не помню). Вот там не было никакого ООП с ORM. На пальцах, конечно, фигово рассказывать. В двух словах, были свои абстракции верхнего уровня, выражающие предметную область, приводились примеры каких-то документов, понятий операций с ними и пр. На уровне ниже строилась модель данных, причём именно в привязке к реляционной модели, где чётко указывалось, типа эта таблица такая-то, для хранения "шапок" документов, эта таблица с их "строками" и т.п. Естественно всё взаимосвязано по уровням, при этом задавались не только таблицы с индексами и отношениями, но и конкретный код хранимок и триггеров и пр. SQL-код задавался тоже на своём лисп-DSL, напоминающий насколько это возможно исходный SQL. Была конкретная привязка к постгресу, были свои ограничения по языку. В итоге "компилировался" конечный SQL. Закладывалась возможность и обратной трансформации, из SQL -> лисп. И, самое главное, делались попытки задания инвариантности моделей, через конструкции по мотивам pattern matching. Далее согласно архитектуре уже конкретного приложения можно привлекать слои создания коллекций в памяти, делать свою обработку, подключать слой презентации и т.д. (в Кложуре те же вэб-фрэймворки строятся на схожих принципах).

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

Имеются свои подобные наработки, но не на таком глубоком уровне, и не на лиспе.

mad_nazgulПоэтому создание "гибкой структуры" - миф.
Гибкая структура уже есть - SQL-сервер ;-)

Ну почему же миф, если отбросить маркетинговую шумиху вокруг NoSQL, то, всё таки, иногда есть вполне оправданные причины быть за рамками SQL-сервера, и нагрузку они могут не вытянуть, и гибко не распределять и т.д. Но и на SQL-серверах можно тоже пытаться выжить, к примеру, скайп же делится своими Skytools .
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38281769
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100У xBase, конечно, хватало тараканов, но как раз без их классов и было проще делать свои абстракции. А при возможности xBase приспособили бы для серверов, но их ключевой индексно-последовательный метод работы с данными в принципе не позволяет реализовать адекватную работу интенсивных параллельных транзакций (или пользователей). Это как раз пример того, что "материал" не может обеспечить требуемую технологию производства.

Какие абстракции в xBase?!
Все крутилось вокруг таблицы.
Желательно одной.
Связь м/у двумя уже такой геморрой.
Есть таблица, с ней можно что-то сделать.
Если есть связь...
Здравствуйте циклы.
Плюс сам язык, который способствовал "лапшекоду".
В этом плане FoxPro был "глотком свежего воздуха", т.к. в нем появились элементы SQL.
Что позволило хоть как-то работать с отношениями м/у таблицами.

PSV100У меня свой опыт и несколько иное мнение. Недавно в соседней теме форума возникал подобный офтоп, поделюсь ссылкой .

У меня то же свой опыт и то же свое мнение. :-)
В ООП приятно и просто моделировать все что угодно.
Просто когда начинают проектировать модель данных, то почему-то забывают.
Что одна модель данных может быть для нескольких моделей ПО (предметной области).
И пытаются перетащить модель данных в ООП.
Что приводит к плачевным последствиям.

PSV100Я несколько лет назад встретил проект на Кложуре, для меня это образцово показательные выступления. Здесь выше давали ссылку на соседнюю тему DB specific ORM , что заставило опять поискать этот проект в инете, не нашёл (и названия не помню). Вот там не было никакого ООП с ORM. На пальцах, конечно, фигово рассказывать. В двух словах, были свои абстракции верхнего уровня, выражающие предметную область, приводились примеры каких-то документов, понятий операций с ними и пр. На уровне ниже строилась модель данных, причём именно в привязке к реляционной модели, где чётко указывалось, типа эта таблица такая-то, для хранения "шапок" документов, эта таблица с их "строками" и т.п. Естественно всё взаимосвязано по уровням, при этом задавались не только таблицы с индексами и отношениями, но и конкретный код хранимок и триггеров и пр. SQL-код задавался тоже на своём лисп-DSL, напоминающий насколько это возможно исходный SQL. Была конкретная привязка к постгресу, были свои ограничения по языку. В итоге "компилировался" конечный SQL. Закладывалась возможность и обратной трансформации, из SQL -> лисп. И, самое главное, делались попытки задания инвариантности моделей, через конструкции по мотивам pattern matching. Далее согласно архитектуре уже конкретного приложения можно привлекать слои создания коллекций в памяти, делать свою обработку, подключать слой презентации и т.д. (в Кложуре те же вэб-фрэймворки строятся на схожих принципах).

ИИ еще никто не разработал.
Были попытки в т.ч. и на lisp'е. ;-)
Процесс моделирования - это процесс творческий.
Можно создать много шаблонов, но всегда найдется задача, в текущем проекте, которая не подходит под шаблон. :-)



PSV100Ну почему же миф, если отбросить маркетинговую шумиху вокруг NoSQL, то, всё таки, иногда есть вполне оправданные причины быть за рамками SQL-сервера, и нагрузку они могут не вытянуть, и гибко не распределять и т.д. Но и на SQL-серверах можно тоже пытаться выжить, к примеру, скайп же делится своими Skytools .

Мы же говорим за реляционную модель... ;-)
По моему проблема NoSQL в том, что нет за ними "мощных" математических теорий.
Все на эвристике.
Соответственно, по идее они могут все, а когда доодит дело до конкретики начинают вылезать "особенности".
SQL - в этом плане более "простой". Всегда точно можно сказать что он может и как может.
И там где мы точно уверены, что SQL - не может. Там его и не надо применять.
С NoSQL такого сказать нельзя, они "по определению" могут все, а вот на практике... ;-)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38281784
Это не СУБД, а фраймворк!
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38281951
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mad_nazgulВ ООП приятно и просто моделировать все что угодно.
Просто когда начинают проектировать модель данных, то почему-то забывают.
Что одна модель данных может быть для нескольких моделей ПО (предметной области).
И пытаются перетащить модель данных в ООП.
Что приводит к плачевным последствиям.

Имхо, это происходит от того, что об ООП не думают как об объектно-ориентированном проектировании, на мозги давит объектно-ориентированное программирование, причём в трактовке мейнстрима, с многоуровневым наследованием, в т.ч. и реализации.

mad_nazgulПо моему проблема NoSQL в том, что нет за ними "мощных" математических теорий.
Все на эвристике.

Отчасти есть, те же исчисления на графах не с потолка. Другое дело, что ещё только идёт процесс становления технологий, устаканивание моделей данных с их физической организацией и т.д. Тех же языков высокого уровня над теми же графами куча разных, причём это не отличия "в диалектах". Вылазят и древние решения, но яко бы уже на новом уровне. Плюс решения в рамках NoSQL, в основном, пока для специализированных задач. В общем, нормальный процесс эволюции, ведь по сравнению с прошлой эпохой только сейчас столкнулись с такими масштабами данных, с такой параллельной нагрузкой, с такими требованиями быстрых реакций и т.д.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282241
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Имхо, это происходит от того, что об ООП не думают как об объектно-ориентированном проектировании, на мозги давит объектно-ориентированное программирование, причём в трактовке мейнстрима, с многоуровневым наследованием, в т.ч. и реализации.Давит причём не на мозги, совсем другое - реальная жизнь со всеми её исключениями из правил и нестыковками.
Презентация, кстати весьма показательна - такую реализацию понятия "(расчётный) счёт" надо выкидывать на помойку. Ещё до прототипирования.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282454
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятина...Тогда нужно ясно показать, как любая МД верхнего уровня может использоваться в Вашей, не ориентированной ни на какую конкретную модель СУБД...Нужно просто взять, например, М2 и показать на примере.
Я не буду ничего показывать про Ваши М. Мне - не нужно.


БредятинаНо, пока, очень важный момент: Вы, все-таки, строго по Дейту делаете - подтвердите еще раз, что класс неизвестной, пока, МД верхнего уровня - это ДОМЕН РМД . То есть, Фамилия Человека, например, - это у Вас класс. Так? А Человек тогда что?
1) Нет у меня МД верхнего уровня.
2) Система строга по Дейту в реляционной проекции, где данные представлены как множество отношения. Но там классов как доменов нет. Там столько скаляры ( то есть данные).
А в проекции, описывается предметная область, нет реляционной модели.Таблицы есть, но это одно их ср-в описание предметной области.

Бредятина"... При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины ."
Покажите на примере, пожалуйста. Зачем? Какой пример, я вообще не понимаю. Оно всё внутри спрятано. Вы ж когда C++ компилятором пользуетесь, Вы ж не думаете, как там таблица имен строится. и вообще про ннее не думаете. Почему это важно?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282492
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovСвоей презентацией вы продемонстировали:
а) универсальность реляционных СУБД.
б) практичность реляционных СУБД
Зачем прикручивать к универсальной и практичной вещи некую надстройку, которых уже и так вагончик - лично мне осталось непонятным. Да. А почти 70 лет истории говорит о том, что фонНеймановские машины так же очень универсальны и практичны. Они принципиально не поменялись за это время, все ими успешно пользуются. Зачем же для них ОО языки придумали? Наверное, что бы было проще ими управлять.

Дело в том, что фон-Неймановские машины реализуют адресный принцип доступа к памяти, но это не единственный принцип организации памяти. Есть еще и ассоциативная память и РМД по моему мнению - это весьма общее и математически строгое описание такой памяти. Современные РСУБД - это такие виртуальные машины с ассоциативной памятью. Для такой машины я сделал ОО транслятор. С той же самомй целью - что бы было проще.

Basil A. Sidorov Что касается декомпозици ...
В основе и ORM-ов и вашего RxO лежит концептуальный прокол - представление о том, что объекты определяют структуру данных.
Отсюда и автогенерация схем и автоматическое построение запросов и аннотации для указания связей и т.п. Я не утверждал, что объекты определяют структуру данных. Я вообще не фанат абсолютизма, когда начинают все подгонять под одну гребенку (типа "всё - это объекты"). Я лишь говорю, что объекты - полезная штука, которую часто удобно использовать, что бы описывать какую то часть предметной области. Раз удобно - пусть будут. Я и от таблиц не отказываюсь (в прототипе этого нет, мне это очевидным кажется). Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте. Я уже коллеге Бердятиен написал, что про "концептуальный уровень" я думать не хочу. Есть типы и классы. А раз нет концептуального уровня, то нет и "концептуальных проколов".

Basil A. SidorovНа самом же деле приложение "видит" данные через призму DML....Я подразумеваю, что приложения вообще нет. Вся модель предметной области - на сервере. Клиент - это только интерфейс. Basil A. Sidorov..., а отображение этих самых DM на объекты - вторично, т.к. сильно зависит от семантики. ... и семантика вся на сервере. И все операции с данными на сервере (в т.ч.запросы, групповые операции) - в терминах этой семантики.

Basil A. SidorovНужно просто принять как факт, что реляционная алгебра - проста. И научиться решать реляционные задачи точно так же,
как в школе решались квадратные уравнения.Фон-неймановская машина тоже проста. Но прикиньте что будет, если Вы скажете "линейная память устроена очень просто. Надо декомпозировать данные до отдельных ячеек памяти и это будет проще чем квадратые уравнения, это ж вообще как 2+2. Поэтому давайте вместо ОО использовать старый добрый ассемблер". (это ваша фраза, переделанная для систем с линейной памятью). Думаю, вас не поймут с такой инициативой.

Дело в том, что и "2+2" и "квадратные уравнения" - это всего лишь инструмент. Чем проще инструмент, тем сложнее его использовать для решения сложных задач. Наоборот, сложный инструмент позволяет упростить решение задач.

И я, честно, вообще не понимаю, в чем Вы меня упрекаете, касательно "реляционной алгебры" :) Я взят понятия и операции формальной реляционной модели и пользуясь только ими построил ОО транслятор для формальной реляционной машины. Можно это рассматривать как одну из реляционных задач. Получилась объектно-ориентированная система управления реляционными БД. Алгебра это никуда не делась. Она активно используется внутри и может быть использована снаружи.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282596
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mad_nazgulВ ООП приятно и просто моделировать все что угодно.
Просто когда начинают проектировать модель данных, то почему-то забывают.
Что одна модель данных может быть для нескольких моделей ПО (предметной области).
И пытаются перетащить модель данных в ООП.
Что приводит к плачевным последствиям.

PSV100Имхо, это происходит от того, что об ООП не думают как об объектно-ориентированном проектировании, на мозги давит объектно-ориентированное программирование, причём в трактовке мейнстрима, с многоуровневым наследованием, в т.ч. и реализации.

Basil A. SidorovДавит причём не на мозги, совсем другое - реальная жизнь со всеми её исключениями из правил и нестыковками.

U-geneЯ не утверждал, что объекты определяют структуру данных. Я вообще не фанат абсолютизма, когда начинают все подгонять под одну гребенку (типа "всё - это объекты"). Я лишь говорю, что объекты - полезная штука, которую часто удобно использовать, что бы описывать какую то часть предметной области. Раз удобно - пусть будут. Я и от таблиц не отказываюсь (в прототипе этого нет, мне это очевидным кажется). Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте. Я уже коллеге Бердятиен написал, что про "концептуальный уровень" я думать не хочу. Есть типы и классы. А раз нет концептуального уровня, то нет и "концептуальных проколов".


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

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

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

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

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

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

- делать иерархию классов, избегая дублирования данных, пытаясь выразить нужные варианты состава полей. При модификации таблицы - рефакторинг иерархии;

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

Короче говоря, вполне реально ынтырпрайз-ООП может вынудить плюнуть и слепить единый универсальный класс для таблицы для всех случаев с единым общим набором полей (или сделать его базовым с protected-данными, затем лепить целевых потомков, лишь публично объявляя нужные поля). И плевать на то, что в ряде случаев в коллекциях будут неиспользуемые данные, это проблемы тех, кто будет оптимизировать через ынтырпрайз-железо.


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

И в рамках ынтырпрайза какой-то поставщик объектного расширения к СУБД может запросто вынудить использовать свой продукт, сам реализовав его уже поверх своего EAV, да ещё подкрепив его обязательными глобальными ID для всех объектов, могут ещё и в виде какого-то GUID (т.е. рядом с возможными естественными ключами будут и ID) и т.д. и т.п. Все оптимизации только "железные".

В общем, с одной стороны через мейнстрим-ООП пытаются дать возможность для упрощения на каком-то уровне (причём не в самом лучшем виде), но, с другой, вся исходная сложность системы и многообразие никуда не делись, их выталкивают в сторону, мол сами разбирайтесь.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282681
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Писал, но куда то ответ делся. Пишу заново.
PSV100Спасибо за презентацию проекта. Пожалуйста.


PSV100 Имеются в виду не политические вопросы, а реальные технические проблемы. Непонятно, как будет функционировать продукт. Я вижу это как расширение SQL сервера. То есть, все что есть в РСУБД сейчас, сохраняется, появляются несколько новых команд. Все остальное полумеры.

PSV100 Предполагаю, что это какой-то "sql-сервер" как прослойка к настоящему серверу СУБД…. Или же это какой-то… Или есть ли какая-то технология выше….Или это только прототип возможного языка на "сервере" ? В видео – прототип, конечно. Но он реализует базовую идею? Без которой никак. А дальше, сверху, по существующей схеме данных, можно генерировать визуальные или программные интерфейсы.

PSV100 Насколько реально возможна трансформация жизненно необходимого исходного SQL ? Не думаю что это нужно или полезно. Если есть возможность ()а возможность есть) надо сохранять, что бы обеспечить обратную совместимость. Что бы можно было, накатив новую версию СУБД (например MS SQL 2022 :) ), ничего н потерять и получить новые возможности (в тч в существующих БД).

PSV100Есть ли возможность оперировать, скажем, рекурсивными запросами. 1) WITH никуда не девается. 2) Для классов тоже можно сделать рекурсию, В прототипе нет; идея как сделать эту рекурсию, понятна…. А, вообще, про рекурсию постоянно спрашивают PSV100Ну, например, если я применю одно объектное выражение, которое заставит систему генерировать sql с подзапросами, а если по-другому - получим соединение таблиц (это, конечно, всё условно, я понимаю, что об оптимизации заботятся изначально). Или есть ли какая-то лазейка для прямой спасительной sql-инъекции, если система чего-то не может. Насчет лазейки – запросто. :) Это как в С++ блок "asm". В целом вопрос очень важный, но смысл им заниматься появляется только тогда, когда дойдем до конкретной реализации на в СУБД.

PSV100…Есть ли какие-то технологии, облегчающие жизнь. Например, как-то так: … Я думал в этом направлении про XML.
UPDATE <класс>[<какое-то where>] SET XMLexpression;

PSV100- Насколько развита ООП-технология как такоЕсли конроль типов выборку ва ? Входной язык в части ОО команд можно накручивать как угодно.
PSV100Есть ли механизм "виртуальных вызовов". Например, пусть я сформирую выборку из объектов разных классов (подклассов) (пока даже не знаю как, возможно, через какой-то "union"), и укажу выполнить метод как-то так: "FOR <выборка> EXEC <метод>", и соответственно я должен ожидать то, что для каждого объекта будет "выполнен" корректный метод нужного класса. И пр. Можно…наверно. :) Во всяком случае, я пока не вижу причин, почему нельзя.

PSV100Ну и ещё один момент. Почему именно ОПП, в принципе, очевидно. Если отбросить вопросы целевого позиционирования продукта, скажем, для своих потребностей, или в дополнение к ООП. Короче говоря, не анализировался ли возможный подход организации каких-то абстрактных типов и независимых операций (по мотивам классов или протоколов типов, к примеру) ?

Всё таки, ООП само по себе имеет немало допущений и неоднозначности, и проблем, для проектирования, моделирования, да и в реализации. От того постоянны разговоры как наследовать прямоугольники с квадратами, "дверь в комнату" сама открывается или её открывает "входящий". Множественное наследование даёт технические проблемы, и, в целом, наследование с понятием субтипа иногда (или не редко) вынуждает приводить реальный тип объектов к верхнему базовому типу, с которым ничего толком и не сделаешь, без вынужденного небезопасного последующего приведения типа. Без относительно строгой типизации вполне можно слонов с мухами складывать и т.д. и т.п. Хотя, собственно, притащить проблемы ОПП в проект можно настолько, насколько эмулируется это ООП.

Это большой разговор.
1)В принципе можно было бы сказать, "ребята, ничего не знаю, в системе такая штука такая возможна, а уж как вы ее применять или понимать будете – не моя забота." :) Это я про множественное наследование.
2)Я и не пытаюсь решить ни вопросы ООП ни вопросы реляционных систем. Там тоже есть много чего, взять хотя бы трехзначную логику, которую не все любят. И все эти вопросы прямиком шуруют в мою систему.
3) Вообще ООП в традиционном понимании плохо подходит для СУБД. Например, создадим мы объект "сотрудник", а этот сотрудник завтра менеджером станет. А у нас менеджеры в отдельном подклассе. В традиционном понимании ООП вообще не ясно что делать, потому что объекты к одному и тому же классу принадлежат от создания до уничтожения и других вариантов нет; соответственно надо объект уничтожить и другой создать. А в нетрадиционном, можно существующий объект "сотрудник" просто подвинуть по иерархии наследования до менеджера. Ничто не мешает и никакой типизации это не вредит.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282683
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Очень плохо, что у ынтырпрайза и нет "концептуального уровня", он и не пытается дать методологию для моделирования, приближённую к реальной жизни. (и дальше, много).... Вы здесь , КМК, схему данных и модель данных попутали. То. что я принципиально отказываюсь от концептуальной модели (от лозунгов типа "всё - объекты" или "все отношения", или от М-моделей от коллеги Бредятина), вовсе не значит, что у меня нет схемы данных. Она есть, она определена в любой момент, ее обязательно можно будет менять.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282693
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneДа. А почти 70 лет истории говорит о том, что фонНеймановские машины так же очень универсальны и практичны. Они принципиально не поменялись за это время, все ими успешно пользуются. Зачем же для них ОО языки придумали? Наверное, что бы было проще ими управлять.ОО-абстракция - практична. В частности тем, что для неё есть простая структура данных. Отличающаяся в деталях для разных языков и даже для разных реализациях одного языка, но есть.
Практичность высокоуровневых абстракций структурного и объектного программирования обусловлена тем, что разработчику не нужно опускаться до уровня ассемблера. Нет, разработчик по-прежнему должен разбираться в эффективности кода, но вот кода этого становится в разы или даже на порядки меньше.
В вашей абстракции такой структуры нет, поэтому рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи, которых нет в объектной модели и придётся работать с таблицами, ключами, индексами и запросами. Вот это и есть - "не летает".Я не утверждал, что объекты определяют структуру данных.Сказавши "а", произнеси и "б".
Структура данных есть, т.к. без этого невозможно использовать нижележащее хранилище.
Если структуру определяют не объекты, тогда что? Ещё одна стройная система костылей и подпорок?Я подразумеваю, что приложения вообще нет. Вся модель предметной области - на сервере.А сервер, значит, святых духом эту модель обрабатывает?Я взят понятия и операции формальной реляционной модели и пользуясь только ими построил ОО транслятор для формальной реляционной машины.Правила ссылочной целостности в вашем ОО-трансляторе как определяются? Как отношения строятся?
И BNF есть?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282829
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-geneВы здесь , КМК, схему данных и модель данных попутали.
...

Это не только я попутал. Тут сами мейнстрим-стандартизаторы направо и налево всё путают. Одни, кто производит инструменты для ER-моделирования, кричат, что ER-модели и есть ваша предметная область, от неё нужно дышать. Другие, кто имеет уже полный стек UML-моделирования, отсылают к моделям классов, компонент и пр. как к первичной песни и т.д. В общем, фиг с ним, с этим мейнстрим-болотом.

Спасибо за ответ. Кроме презентации я посмотрел и "бумажные" сочинения, в целом, картина прорисовалась.

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

Правильно ли я понимаю смысл db-класса и наследования?

Пусть есть класс "сотрудники", у него есть два потомка - "менеджеры" и "уборщики". Данные, записанные непосредственно в "сотрудники" не должны быть видны из потомков, также "менеджеры" не должны видеть "уборщиков" и наоборот. Но через класс "сотрудники" мы должны видеть всех или нет? (т.е. непосредственно "сотрудников" и всех "потомков"). Или как состыковывать данные, когда создаётся объект "менеджер" и его также нужно зафиксировать в "сотрудниках" ?

Кстати, получается, что класс автоматом означает наличие "коллекции" объектов, т.е. для любого класса можно заполнять его объектами, даже если он некий технический, невыражающий конечную прикладную сущность, используется как обобщение кода для наследования. Здесь можно попробовать уменьшить противоречия в ООП, и дать правило, что класс это всегда "коллекция" (что и есть), подкреплённый понятием субтипа (некие субколлекции). Тогда есть потребность в дополнительном механизме для обобщённого кода. Например, структурные множества "SET OF" можно иметь не только встроенными в класс, но и внешние независимые (типа "CREATE SET ..."), затем их можно подключать в классы (не через наследование).

Также не хватает понятие модулей (пакетов, областей имён и т.п.) с интерфейсами (т.е. объявления публичности, private/public элементов).

Теперь я попытаюсь спроектировать модуль XX и YY, которые имеют общий класс CCC. Если класс - это непосредственная коллекция объектов, то создавая классы в каждом модуле как XX.CCC и YY.CCC (по мотивам того, как учат делать ER-схемы данных в рамках логической модели), то я сделаю независимые коллекции, когда мне нужно единое хранилище, для многих задач (причём, как бы с разным составом полей для каждого логического модуля). Тогда мне нужен, ну... пусть отдельный модуль ZZ, с общим функционалом для многих других, где я в т.ч. сделаю общий класс ZZ.ССС. Теперь в модулях XX и YY я сделаю потомков от этого класса, XX.CCCxx и YY.CCCyy. Но, для меня до конца не понятна концепция класса, вроде как класс означает физическое (а также и некое логическое по отношению к потомкам) хранилище. Поэтому вроде как нужно эти классы убрать (или не вводить) из XX и YY. Но мне нужно как-то отразить, что в модели каждого этого модуля используется (или является частью) общий класс ZZ.ССС. Т.е. нужны какие-то декларации вида "USING ZZ.CCC (<список полей>)", где опционально можно задать список полей (и методов), используемых в модуле, плюс "алиасы" для имён и пр.

Одним словом, до конца не ясна концепция класса.

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


Тут, всё таки, нужно подметить особенность типового мейнстрим-ООП: начинается всё с простых классов, затем может появится понятие private/public/virtual и пр. наследование, абстрактные классы и интерфейсы, "методы-расширения", а то и traits с mixin, или даже "case"-классы с implicit-элементами и т.д.


P.S. Собственно, меня проблематика интересует не столько с позиции целесообразности или возможности полной замены SQL, а больше сам концептуальный взгляд на проектирование и моделирование в подобной системе как RxO.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282845
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ не буду ничего показывать про Ваши М. Мне - не нужно.
Покажите про любую свою.
Вы написали: "... в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте."
Что значит "мне не нужно"??? Зачем начали пояснять что-то, а по существу не хотите говорить?))
U-gene1) Нет у меня МД верхнего уровня.
Этого просто не может быть, я уверен. Докажите это - продемонстрировав описание той же самой примитивной "задачи", которая использовалась для сравнения моделей верхнего уровня. Опровергните всю ту тему, показав, что эта задача решается в Вашей системе без всякой МД верхнего уровня. Но при этом, и просто РСХОД (можете для удобства использовать некорректный термин РСУБД) применять почему-то хуже, чем Вашу систему + РСХОД. Вот на этом совсем простом примере и поясните. Или напишите (как это обычно делают): "На таком простом примере невозможно продемонстрировать суть предлагаемой технологии".
U-gene2) Система строга по Дейту в реляционной проекции, где данные представлены как множество отношения. Но там классов как доменов нет. Там только скаляры (то есть данные).
А в проекции, в которой описывается предметная область, нет реляционной модели.Таблицы есть, но это одно из средств описания предметной области.
Я правильно исправил ошибки в Вашем тексте???
Итак, в проекции предметной области нет РМД и нет никакой другой модели! Как же описывается предметная область? Какие элементы описания (если бы МД была, это были бы элементы структуры этой МД - первый аспект МД) используются?
Далее, Вы пишете, что Ваши классы используются как домены этих таблиц. А что же представляют собой эти таблицы? В РМД отношения представляют и сущности и связи между сущностями. А связи в свою очередь, моделируются, то с помощью отношений, то с помощью ключей.
13755686
14020991
Это и есть одна из причин того, что РМД не удалось еще никому применить для решения какой-либо задачи, то есть, приходится использовать архитектуру "МД верхнего уровня+маппинг+РМД". Вероятно, "Ваша система+РСХОД" как раз и делает возможным применение РМД для практических задач без использования МД верхнего уровня и маппинга по всем трем аспектам МД. Так проясните этот важный вопрос))
U-geneЗачем? Какой пример, я вообще не понимаю. Оно всё внутри спрятано. Вы ж когда C++ компилятором пользуетесь, Вы ж не думаете, как там таблица имен строится. и вообще про нее не думаете. Почему это важно?
Выше про пример написал подробно. И про то зачем он нужен. Чтобы понять - как Вы обходитесь без моделирования данных.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282849
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте. Я уже коллеге Бердятине написал, что про "концептуальный уровень" я думать не хочу. Есть типы и классы. А раз нет концептуального уровня, то нет и "концептуальных проколов".
Вы же писали, что "мои классы - это домены таблиц"? Теперь говорите, что всю предметную область можно описать доменами таблиц (без использования таблиц)??? Вот почему так важен простейший пример))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282853
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneТо. что я принципиально отказываюсь от концептуальной модели (от лозунгов типа "всё - объекты" или "все отношения", или от М-моделей от коллеги Бредятина), вовсе не значит, что у меня нет схемы данных. Она есть, она определена в любой момент, ее обязательно можно будет менять.
Нет, Вы отказываетесь не от концептуальной модели, а именно от логической МД верхнего уровня)) Поэтому и нужно пояснить на примере...
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282856
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100...Одним словом, до конца не ясна концепция класса...
Дейту ясна. См. про первую грубейшую ошибку.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38282984
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим НС EAV это конечно возможно, но запросы будут гораздо сложнее, их тяжело поддерживать и оптимизировать. Не все радужно с индексированием.


Тут же все просто.
С EAV это возможно, без EAV это невозможно.

Использовать XML в реляционной субд - это путь в никуда, зачем тогда тебе реляционная субд? Бери XML-хранилище какое-то.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38283013
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivМаксим НС EAV это конечно возможно, но запросы будут гораздо сложнее, их тяжело поддерживать и оптимизировать. Не все радужно с индексированием.


Тут же все просто.
С EAV это возможно, без EAV это невозможно.

Использовать XML в реляционной субд - это путь в никуда, зачем тогда тебе реляционная субд? Бери XML-хранилище какое-то.

XML уже в прошлом, я просто упомянул это решение (пусть плохое и не подходящее) как одно из альтернатив для EAV. Сейчас смотрю в сторону графов.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38283014
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivС EAV это возможно, без EAV это невозможно.Главное не путать слова «не умею» и «невозможно». Есть куча систем реализовпвших гибкость (и даже с наследованием) без EAV.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38283044
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Максим Н
XML уже в прошлом, я просто упомянул это решение (пусть плохое и не подходящее) как одно из альтернатив для EAV.
Может XML - пусть плохое и не подходящее, но все таки в отличии от EAV относится к полноценным типам МД - свои средства структурирования, язык запросов. У EAV все это от РМД: т.е. как бы типа плохая РМД.
В частности, есть вроде СУБД ХML.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285311
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneДа. А почти 70 лет истории говорит о том, что фонНеймановские машины так же очень универсальны и практичны. Они принципиально не поменялись за это время, все ими успешно пользуются. Зачем же для них ОО языки придумали? Наверное, что бы было проще ими управлять.ОО-абстракция - практична. В частности тем, что для неё есть простая структура данных. Отличающаяся в деталях для разных языков и даже для разных реализациях одного языка, но есть.
Практичность высокоуровневых абстракций структурного и объектного программирования обусловлена тем, что разработчику не нужно опускаться до уровня ассемблера. Нет, разработчик по-прежнему должен разбираться в эффективности кода, но вот кода этого становится в разы или даже на порядки меньше.
В вашей абстракции такой структуры нет, поэтому рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи, которых нет в объектной модели и придётся работать с таблицами, ключами, индексами и запросами. Вот это и есть - "не летает".Вы сейчас сами с собой спорите, и я Ваши переходы от одной мысли к другой уловить опять не могу. Но по отдельным кускам пройтись смогу.
1) "ОО- абстракция практична." То есть ею пользоваться проще и удобнее. Ну а я о чем?
2) "кода этого становится в разы или даже на порядки меньше." - и опять тоже самое
3) "В вашей абстракции такой структуры нет"... какой структуры нет? Вы презентацию видели? Структура объектов четко описана.
4) "рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи" - не окажется,ни рано ни поздно. Какую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины. Потому язык изначально построен так, что бы эффективно транслироваться, вместе с ключами индексами и запросам.


Basil A. SidorovBasil A. SidorovВ основе и ORM-ов и вашего RxO лежит концептуальный прокол - представление о том, что объекты определяют структуру данных.Я не утверждал, что объекты определяют структуру данных.Сказавши "а", произнеси и "б".
Структура данных есть, т.к. без этого невозможно использовать нижележащее хранилище.
Если структуру определяют не объекты, тогда что? Ещё одна стройная система костылей и подпорок?Вы первое предложение абзаца прочитали, и сразу в бой? хорошо, специально для Вас постараюсь уместить свою мысль в одно предложение. Я не утверждал, что только объекты определяют структуру данных, как это Вы имели в виду в Вашем предыдущем посте, о чем Вы видимо уже забыли.

Basil A. SidorovЯ подразумеваю, что приложения вообще нет. Вся модель предметной области - на сервере.А сервер, значит, святых духом эту модель обрабатывает?Нет. Посредством детерминированного алгоритма.

Basil A. SidorovПравила ссылочной целостности в вашем ОО-трансляторе как определяются? Как отношения строятся?
И BNF есть? Ну здравствуйте! :) Ну а как Вы себе представляете создание транслятора без BNFа ? :) Определяются и строятся, здесь все прописано. И ссылки и внешние ключи в примере презентации есть.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285419
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneКакую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины.Ладушки.
Можно увидеть пример описания RxO, функционально эквивалентный отношению "многие ко многим" для задачи "студенты и предметы"?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285497
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаВы написали: "... в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте."Я дальше написал, что не настаиваю и спорить не буду.Еще раз могу это повторить.БредятинаU-gene1) Нет у меня МД верхнего уровня.
Этого просто не может быть, я уверен.Ок, давайте скажу по другому. Когда я говорю про свою систем я не думаю про какую-либо модель. Я предлагаю
-- простую систему типов, которую пользователь может использовать для описания предметной области (назовем это входной системой типов) и
-- простой переход к реляционному представлению данных о предметной области, описанных с использованием этой системы типов, с сохранением семантики данных (точнее даже, на основе этой семантики) .

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

И когда я гляжу на эту входную систему типов и сравниваю ее с Вашими М-моделями, я не вижу вариантов, где ваши сущности и/или связи не могли бы быть напрямую выражены с использование моих классов и/или таблиц, и возможных связей между классами и/'или между' таблицами.

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

Я в детали Ваших М-моделей я влезать не хочу. Ну...вдруг это перечень не полный? Я начну его по пунктам анализировать, а окажется Вы что-то упустили. Нет, не буду :)

Например Дейт , говоря о первой серьезной ошибке, рассматривает два варианта того, как соотносятся ОО и Р концепции
класс = домен
класс = отношение.
А RxO (даже в прототипе) реализует принцип, согласно которому данные множества классов представлены в виде множества отношений ("объектных видов"), и эти множества соотносятся связью M:N, то есть данные из одного класса могут быть представлены во множестве объектных видов, а один объектный вид может представлять данные из множества классов. Объектное описание ортогонально реляционному представлению, и единственное что их связывает - общие имена. Этот принцип ни в с одним из вариантов Дейта никак не соотносится. Дейт не то, что не прав, но не полон. С учетом того, что эта неполнота наблюдается в исходном посыле, я не даже не рассматриваю все его дальнейшие выводы о том, какое решение может быть правильным , как критерий истины. А в том, какое решение будет неправильным он, конечно, прав, как и во многом другом. Так же как и Вы. :)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285507
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneКакую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины.Ладушки.
Можно увидеть пример описания RxO, функционально эквивалентный отношению "многие ко многим" для задачи "студенты и предметы"?Я всех задач наизусть не помню, к сожалению. Детализируете, пожалуйста.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285514
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ всех задач наизусть не помню, к сожалению. Детализируете, пожалуйста.Есть несколько студентов и несколько предметов.
Каждый студент должен выбрать несколько предметов.

P.S. Где, простите, появилась альтернативная реальность с новым толкованием отношения "многие ко многим"?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285576
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Но, всё таки, вопрос на счёт концептуального уровня до конца не ясен. Конечно, сейчас есть только прототип, много чего ещё не реализовано, я не в курсе того, что запланировано, и, в целом, много чего не знаю (и всяческих деталей изложенных материалов уже не помню). Поэтому, я могу ошибаться, но хотелось бы понять, как организовать проектирование в RxO.Я пока не готов ответить в деталях. Но в общем, если рассматривать методы "сверху-вниз" и "снизу вверх", то вырисовывается какое-то "навстречу" :).
PSV100Правильно ли я понимаю смысл db-класса и наследования? Да. И все остальное. Атрибуты и методы вместе, их специффкация отделена от реализации (для меня это = инкапсулировано), эту реализацию можно переопределять (полиморфизм), итд.

PSV100Пусть есть класс "сотрудники", у него есть два потомка - "менеджеры" и "уборщики". Данные, записанные непосредственно в "сотрудники" не должны быть видны из потомков, также "менеджеры" не должны видеть "уборщиков" и наоборот. Но через класс "сотрудники" мы должны видеть всех или нет? (т.е. непосредственно "сотрудников" и всех "потомков"). Или как состыковывать данные, когда создаётся объект "менеджер" и его также нужно зафиксировать в "сотрудниках" ?.Не очень понял. Объекты класса наследника являются объектами родительского класса, но не наоборот. Родительский класс включает объекты дочерних классов, но не наоборот.

PSV100Кстати, получается, что класс автоматом означает наличие "коллекции" объектов, т.е. для любого класса можно заполнять его объектами, даже если он некий технический, невыражающий конечную прикладную сущность, используется как обобщение кода для наследования. Здесь можно попробовать уменьшить противоречия в ООП, и дать правило, что класс это всегда "коллекция" (что и есть), подкреплённый понятием субтипа (некие субколлекции). Тогда есть потребность в дополнительном механизме для обобщённого кода. Например, структурные множества "SET OF" можно иметь не только встроенными в класс, но и внешние независимые (типа "CREATE SET ..."), затем их можно подключать в классы (не через наследование). Можно. Это языковые штуки.

PSV100Также не хватает понятие модулей (пакетов, областей имён и т.п.) с интерфейсами (т.е. объявления публичности, private/public элементов).... Это КМК полезные штуки, которые тоже можно реализовать.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285599
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Схематично
Вариант с классами (доступен сейчас)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CLASS ПРЕДМЕТЫ
{
   ...
}

CLASS СТУДЕНТЫ
{
   ...
   изучает SET OF
   {
      предмет ПРЕДМЕТЫ
      ...
   } КEY предмет
}

В полной реализации, когда будут доступны таблицы, можно воспользоваться ими
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CLASS ПРЕДМЕТЫ
{
   ...
}

CLASS СТУДЕНТЫ
{
    ...
}

ТABLE Изучает
{
   предмет ПРЕДМЕТЫ
   студент СТУДЕНТЫ
} КEY (предмет, студент)


PS на PS. В презентации классы GOODS и SHIPMENTS связаны отношением многие-ко-многим. Я подумал, что раз Вы это не заметили, то может быть "альтернативная реальность" у Вас, поэтому уточнил.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285615
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneВариант с классами (доступен сейчас)
...А как реализуется разрешение или запрет каскадного удаления предметов?
Скажем, вуз решил сократить непопулярную дисциплину?В полной реализации, когда будут доступны таблицы, можно воспользоваться имиИ чем этот вариант лучше изучения одного или нескольких SQL-диалектов?Я подумал, что раз Вы это не заметили, то может быть "альтернативная реальность" у Вас, поэтому уточнил.Вы преподавали?
Анекдот про "я им два часа объяснял, уже сам всё понял, а до них так и не дошло" - знаете?
Презентация не лучший, мягко говоря способ излагать основы.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285721
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ дальше написал, что не настаиваю и спорить не буду. Еще раз могу это повторить.
И я сразу написал, что не нужно ни настаивать, ни спорить. Я же не спорю. Я попросил пояснить, всего лишь.
U-geneОк, давайте скажу по другому. Когда я говорю про свою систему я не думаю про какую-либо модель. Я предлагаю
-- простую систему типов, которую пользователь может использовать для описания предметной области (назовем это входной системой типов) и
-- простой переход к реляционному представлению данных о предметной области, описанных с использованием этой системы типов, с сохранением семантики данных (точнее даже, на основе этой семантики).
Пока, можно только гипотетически предположить, что система типов выполняет роль отношений РМД...
U-geneПри этом входная система типов включает и классы и таблицы. (в прототипе только классы? табличные структуры обсуждаются)
По Дейту (а Вы подтвердили, что делаете по Дейту) класс - это домен (то есть, класс не соответствует отношению РМД). И Вы говорили ранее о доменах таблиц. Но самих таблиц нет. Каким же образом, набор свойств типа сущности (при том, что нет никаких типов сущности) становится неким отношением в РМД? Ведь простейший пример использовался в теме по ссылке. Почему нельзя на нем пояснить?
U-gene-- Классы очень похожи на то, что существует в традиционных ОО языках. Единственное условие - состояние объекта описывается набором значений типов, допускающих реляционное присваивание. То есть, атрибутами объектов могут быть скаляры, кортежи и назовем это "табличные атрибуты" ТА (в прототипе только скаляры и ТА). Это условие - залог оптимальной трансляции структур. Все объекты уникальны по определению, но в классе для объектов могут быть заданы явные ключи. Связи между классами могут быть определены как с использованием ссылок, так и внешними ключами
Итак, Вы допускаете первое серьезное заблуждение , все-таки?????
U-gene-- Таблицы похожи на реляционные таблицы. Единственное отличие заключается в том, что я могу классы, которые есть множества объектов, использовать как домены таблиц (более строго, доменом являются множество ссылок на объекты класса). Кроме того, классы и таблицы могут быть связаны внешними ключами.
Здесь опять по Дейту)) Он и не отрицает, что значением атрибута отношения может быть значение переменной отношения...
U-geneИ когда я гляжу на эту входную систему типов и сравниваю ее с Вашими М-моделями, я не вижу вариантов, где ваши сущности и/или связи не могли бы быть напрямую выражены с использование моих классов и/или таблиц, и возможных связей между классами и/'или между' таблицами.
Уже не я один, как видите, просит Вас рассмотреть пример, рассмотренный в теме по ссылке (точнее, пример аналогичного класса).
Что сложного в использовании М2 для этого примера?
U-geneВообще, во всех разговорах и спорах о "моделях" обычно рассматриваются какие то универсальные штуки, позволяющие и описать предметную область и представить данные о предметной области. А я предлагаю не модель, а очень простой способ перехода от достаточно произвольного описания предметной области (классы + таблицы) к реляционному представлению данных о этой предметной области.
Чем именно "достаточно произвольное описание предметной области" отличается от логической МД? Давайте остановимся на аспекте структуры. Он же есть, правильно? Вы хотите, в частности, сказать, что связи между типами сущностей моделируются с помощью классов и таблиц, подобно тому, как в РМД они моделируются при помощи отношений и ключей.
U-geneЯ в детали Ваших М-моделей я влезать не хочу. Ну...вдруг это перечень не полный? Я начну его по пунктам анализировать, а окажется Вы что-то упустили. Нет, не буду :)
Никто же не просил Вас ничего анализировать. Ни спорить, ни настаивать, ни анализировать. Просто взять М2, банальный пример из темы, и показать как это делается в Вашей системе.
U-geneНапример Дейт , говоря о первой серьезной ошибке, рассматривает два варианта того, как соотносятся ОО и Р концепции
класс = домен
класс = отношение.
Дейт считает, что класс = домен.
U-geneА RxO (даже в прототипе) реализует принцип, согласно которому данные множества классов представлены в виде множества отношений ("объектных видов"), и эти множества соотносятся связью M:N, то есть данные из одного класса могут быть представлены во множестве объектных видов, а один объектный вид может представлять данные из множества классов.
А Вы так не считаете. Это понятно. И теперь еще актуальнее становится пример описания предметной области в Вашей логической МД, которой. как бы, нет))
U-geneОбъектное описание ортогонально реляционному представлению, и единственное что их связывает - общие имена.
Приведите пример!!!)))
U-geneЭтот принцип ни в с одним из вариантов Дейта никак не соотносится. Дейт не то, что не прав, но не полон. С учетом того, что эта неполнота наблюдается в исходном посыле, я не даже не рассматриваю все его дальнейшие выводы о том, какое решение может быть правильным , как критерий истины. А в том, какое решение будет неправильным он, конечно, прав, как и во многом другом. Так же как и Вы. :)
Это никак не объясняет, почему на уровне хранения МД есть, а на уровне описания предметной области никакой МД нет. Вероятно, Вы считаете, что МД нет, потому что нет второго и третьего аспектов? ОЦ и манипулирования? Это как же так?
В РМД ведь тоже нет ни сущностей, ни связей между ними, но это же не означает, что РМД не МД...
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285730
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneСхематично
Вариант с классами (доступен сейчас)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CLASS ПРЕДМЕТЫ
{
   ...
}

CLASS СТУДЕНТЫ
{
   ...
   изучает SET OF
   {
      предмет ПРЕДМЕТЫ
      ...
   } КEY предмет
}

Это детально раскритиковано, в том числе и Дейтом. Несимметричный доступ. _мод так тоже делает в своей системе (см. тему про МД верхнего уровня).
U-geneВ полной реализации, когда будут доступны таблицы, можно воспользоваться ими
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CLASS ПРЕДМЕТЫ
{
   ...
}

CLASS СТУДЕНТЫ
{
    ...
}

ТABLE Изучает
{
   предмет ПРЕДМЕТЫ
   студент СТУДЕНТЫ
} КEY (предмет, студент)


Поясните, пожалуйста, почему конкретно не может быть (а это же очевидно из Вашего примера, что не может быть )
CLASS Изучает
?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285919
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneВариант с классами (доступен сейчас)
...А как реализуется разрешение или запрет каскадного удаления предметов?
Скажем, вуз решил сократить непопулярную дисциплину?Хороший вопрос, такие помогают. В прототипе этого нет. Идея ясна, механизм тоже. Это должно определятся для атрибутов, когда они реализуются как хранимые, можно использовать синтаксис близкий к традиционному.

ALTER CLASS СТУДЕНТЫ
REALIZE
изучает SET OF
{
предмет ПРЕДМЕТЫ ON DESTROY CASCADE
...
} КEY предмет
AS STORED

[quot Basil A. Sidorov]В полной реализации, когда будут доступны таблицы, можно воспользоваться имиИ чем этот вариант лучше изучения одного или нескольких SQL-диалектов?[quot] 1) У коллеги Бредятины много М. Я в одном диалекте реализую два разных варианта
2) C какими существующими SQL диалектами будем сравнивать? Какой SQL диалект поддерживает полноценные, привычные и понятные классы декларативным образом? В каком SQL диалекте я могу обращаться с запросами непосредственно к классу (а не к типизированным таблицам, построенным на основе лиловых UDT)?

Basil A. Sidorov Вы преподавали?
Анекдот про "я им два часа объяснял, уже сам всё понял, а до них так и не дошло" - знаете? Презентация не лучший, мягко говоря способ излагать основы.Не преподавал. Знаю :). Вот, например, какие то то основы . Но, по опыту, продвигать чистую теорию занятие вообще неблагодарное. А в презентации вживую видно, что эта теория уже работает.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285956
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Бредятина

Я выделю Ваш КМК ключевой вопрос.

БредятинаU-geneОбъектное описание ортогонально реляционному представлению, и единственное что их связывает - общие имена.
Приведите пример!!!)))

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

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

Кстати
Бредятина...Вероятно, Вы считаете, что МД нет, потому что нет второго и третьего аспектов? ОЦ и манипулирования? Это как же так?... Посмотрите видео!!! Там и ключи есть, и методы, и ad-hoc запросы. Как то так.

И еще. Вы все же читайте целыми постами и до конца. Хотя бы для того, что бы внутри Вашего поста не было Ваших же раздумий и метаний, за Дейта я или против. Я за себя. :)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38285965
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаU-geneСхематично
Вариант с классами (доступен сейчас)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CLASS ПРЕДМЕТЫ
{
   ...
}

CLASS СТУДЕНТЫ
{
   ...
   изучает SET OF
   {
      предмет ПРЕДМЕТЫ
      ...
   } КEY предмет
}

Это детально раскритиковано, в том числе и Дейтом. Несимметричный доступ. _мод так тоже делает в своей системе (см. тему про МД верхнего уровня). Я всего дейта наизусть не помню. Давйте пожалуста сслочку. И вообще, что значит "несимметричный доступ"? :)
БредятинаU-geneВ полной реализации, когда будут доступны таблицы, можно воспользоваться ими
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CLASS ПРЕДМЕТЫ
{
   ...
}

CLASS СТУДЕНТЫ
{
    ...
}

ТABLE Изучает
{
   предмет ПРЕДМЕТЫ
   студент СТУДЕНТЫ
} КEY (предмет, студент)


Поясните, пожалуйста, почему конкретно не может быть (а это же очевидно из Вашего примера, что не может быть )
CLASS Изучает
? Да шут ее знает почему. :) По мне, с классом коряво получается, но если хотите - попробуйте. А если есть вариант связного объяснения - валяйте. :) Мне кажется, он у Вас есть.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286047
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-genePSV100Пусть есть класс "сотрудники", у него есть два потомка - "менеджеры" и "уборщики". Данные, записанные непосредственно в "сотрудники" не должны быть видны из потомков, также "менеджеры" не должны видеть "уборщиков" и наоборот. Но через класс "сотрудники" мы должны видеть всех или нет? (т.е. непосредственно "сотрудников" и всех "потомков"). Или как состыковывать данные, когда создаётся объект "менеджер" и его также нужно зафиксировать в "сотрудниках" ?.

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

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

ALTER Сотрудники[<такое-то where>] TO Менеджеры

U-geneВ полной реализации, когда будут доступны таблицы, можно воспользоваться ими

CLASS ПРЕДМЕТЫ
{
...
}

CLASS СТУДЕНТЫ
{
...
}

ТABLE Изучает
{
предмет ПРЕДМЕТЫ
студент СТУДЕНТЫ
} КEY (предмет, студент)

Имхо, некие таблицы могут нарушить "ООП-гармонию", многие заявят, что уже попахивает костылями. Собственно, отчасти может быть это и так. Если ставить задачу просто упрощения написания SQL-кода, то, в принципе, можно подойти к проблеме именно в рамках РМД и SQL. Здесь на сайте когда-то представляли проект Macro T-SQL ( форум , плюс связанный проект TSQLMacro ). Проекты, конечно, имеют свою специфику, но я просто говорю о том, что есть потенциал.
В Вашем случае, имхо, лучше оставаться в рамках ООП, раз такая пьянка.

Лично я в последние времена размышляю иногда над другими таблицами, как раз в рамках проектирования и моделирования. Речь идёт о таблицах решений (на всякий случай, книга Хамби), об организации "распределенных" связанных таблиц, плюс их увязка с объектным-ориентированным проектированием (скорее всего, без многоуровневого наследования). Конкретностей пока выразить не могу.
(кстати, есть ещё современные мотивы таблиц решений, как здесь , для прямой разработки спорно, но для ряда разборов полётов полезно).

Спасибо за ответ.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286049
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
БредятинаU-geneСхематично
Вариант с классами (доступен сейчас)

CLASS ПРЕДМЕТЫ
{
...
}

CLASS СТУДЕНТЫ
{
...
изучает SET OF
{
предмет ПРЕДМЕТЫ
...
} КEY предмет
}

Это детально раскритиковано, в том числе и Дейтом. Несимметричный доступ. _мод так тоже делает в своей системе (см. тему про МД верхнего уровня).

А можно в двух словах подробнее о чём речь ? Или направить куда-то почитать.


Вот вырезка из "официальной документации":
Код: sql
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.
CREATE CLASS BANKS
	( Name STRING //component-scalar
);

CREATE CLASS CONTRACTORS
(   Name STRING,
	Bank BANKS, // component-reference
	ID STRING
)KEY(ID); //class keys are non-obligatory

CREATE CLASS GOODS
( 	Art STRING;
	Turnover SET OF //component-relation
	( 	DocN STRING,
		Cntr CONTRACTORS, //reference attribute
		Pieces INTEGER
	)KEY(DocN), //component key
	Pieces INTEGER //...remain on stock
)KEY(Art); //class key

CREATE CLASS DOCS
( 	DocN STRING,
	Date DATETIME,
	Comment STRING,
	Cntr CONTRACTORS,
	Items SET OF
	( 	Art STRING,
		Pieces INTEGER
	)KEY(Art),
	DoShip(inDate DATETIME) //method
)KEY(DocN)
REFERENCE Items(.Art)
	ON GOODS(.Art) //foreign key



Вот пример запроса, где есть выборка из "Items" не только одного конкретного объекта, т.е. не через явную ссылку или переменную:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT
	#d.DocN
	#d.Items.Art
	#d.Items.Pieces
FROM DOCS[.Cntr.Name = "TheRetail"] #d;

	The result is

DocN        Items   Items
	      .Art     .Pieces
---------------------------
Ship3
Sale1 	Axe 	50
Sale1 	Tie 	50



Можно теоретически (пока предположить) выбрать все "Items" из всех классов как-то так:
Код: sql
1.
2.
3.
4.
5.
SELECT
	.CLASS.NAME
	.Items.Art
	.Items.Pieces
FROM *;


Здесь есть вопрос на счёт типизации, ведь в классе DOCS не указано явно имя типа для Items, и возможно в разных классах будут свои Items и разного типа. Но пусть пока действует "утиная типизация".
Или вот так мы получаем ссылку на объект:
Код: sql
1.
2.
3.
4.
NEW CONTRACTORS WITH SET
	.Name:="TheRetail",
	.Bank:=(FIRST OF BANKS<.Name="TheBank">),
	.ID:="CoID002";


где через "FIRST OF ..." возвращается ссылка на объект (или null, наверное), через "метасистему" или "RTTI" можем узнать класс объекта, составить список ссылок на класс, добраться до нужных классов и их свойств и т.д.

Короче говоря, на первый взгляд, вроде как можно вертеть в разные стороны. Или это только на первый взгляд ?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286110
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneУ коллеги Бредятины много М. Я в одном диалекте реализую два разных варианта.
Это, конечно же, не так. У всех своя М. Одна. В том числе, и у Вас. Постепенно проясняется, что это МД, описанная _мод.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286121
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneПосмотрите же видео!!! )))
На данный момент посмотрел 4 (четыре) раза.
U-geneЯ там долго объясняя почему, описав всего три класса, связанных ссылками, я могу считать, что в системе тем самым определено существования огромного числа отношений, где представлены данные объектов этих классов, и эти отношения пользователь может использовать, вообще не задумываясь об случившемся переходе от объектов к отношениям.
Проще нужно сделать.
Два класса (с вложенной коллекцией, содержащей ссылки):
К1) Документ-накладная (коллекция операций отгрузки, каждая из которых содержит ссылку на отгруженный товар)
К2) Товар
И три отношения:
О1) Документ ("шапка" накладной)
О2) Операция отгрузки (запись в документе)
О3) Товар
Пользователь не знает о существовании каких-то там отношений на уровне системы хранения. Я именно эту очевидную ситуацию рассматриваю. А не программистов, которые решают разные задачи перманентно, потому что пользователи просто не в состоянии их решить при использовании реляционной системы.
У пользователя есть К1 и К2. Как, например, получить данные об отгрузках конкретного товара? В системах с симметричным доступом можно использовать интерактивный интерфейс (неотъемлемая часть современной СУБД), и это, действительно, может сделать пользователь. А как это сделать в случае, когда целевой объект "запрятан" внутри другого "объекта". Мы даже не знаем о его существовании (а программист знает - на уровне системы хранения).
U-geneВ остальном Вы что то понавыдумывали, чего у меня нет, в какие-то дебри забрели и меня туда же тащите. Я не пойду, ибо боюсь увязнуть в этих ваших вариантах.
Приведите хотя бы один пример выдумки. Пока, это Ваше высказывание не корректно. Отмазка, грубо говоря)))
U-geneПосмотрите видео!!! Там и ключи есть, и методы, и ad-hoc запросы. Как то так.
))))) То есть, МД верхнего уровня налицо. И почему же так сложно начать именно с ее описания???
U-geneИ еще. Вы все же читайте целыми постами и до конца. Хотя бы для того, что бы внутри Вашего поста не было Ваших же раздумий и метаний, за Дейта я или против. Я за себя. :)
Поскольку это очевидно и без чтения, то непонятно зачем Вы это написали)) Мои метания абсолютно симметричны Вашим. Как только прекратятся Ваши метания, и Вы опишете, наконец, используемую МД верхнего уровня, прекратятся и мои метания. Я, либо внесу ее в перечень МД верхнего уровня, либо пойму, что это одна из уже описанных в нем моделей.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286129
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneДавайте пожалуйста ссылочку. И вообще, что значит "несимметричный доступ"? :)
Вся глава 25 (И8). В частности, стр. 1031.
U-geneДа шут ее знает почему. :) По мне, с классом коряво получается, но если хотите - попробуйте. А если есть вариант связного объяснения - валяйте. :) Мне кажется, он у Вас есть.
Что значит "кажется"?
14020991
Итак, без таблиц тоже можно. Следовательно, для рассмотренного примера (обозначим пример со Студентами и Предметами - П1) варианты идентичны: классы ничем не отличаются от таблиц в аспекте структуры. Правильно? Тогда перейдем к П2 - Документ-Отгрузка-Товар...
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286131
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100А можно в двух словах подробнее о чём речь ? Или направить куда-то почитать.
13545785
и вся эта тема...
Выше дал ссылку на Дейта.
PSV100Короче говоря, на первый взгляд, вроде как можно вертеть в разные стороны. Или это только на первый взгляд ?
Да, только на первый. Вы говорите о программистах и СХОД, а я говорю о не программистах и СУБД.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286597
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаПроще нужно сделать.
Два класса (с вложенной коллекцией, содержащей ссылки):
К1) Документ-накладная (коллекция операций отгрузки, каждая из которых содержит ссылку на отгруженный товар)
К2) Товар
И три отношения:
О1) Документ ("шапка" накладной)
О2) Операция отгрузки (запись в документе)
О3) Товар
То есть Вы считаете, что эти два класса и три отношения проще чем мои просто два класса? Сильно :)

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

Схема

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CLASS ПРЕДМЕТЫ
{
   Название
   ...
}

CLASS СТУДЕНТЫ
{
   
   Имя
   ...
   изучает SET OF
   {
      предмет ПРЕДМЕТЫ
      ...
   } КEY предмет
}

Запрос, который вытаскивает данные по ссылке
Код: plaintext
SELECT Название FROM СТУДЕНТЫ[.Имя = 'Бредятина']. Изучает. Предмет
Результат - названия всех предметы, которые изучает Бредятина

Запрос, который вытаскивает данные "против" ссылке
Код: plaintext
SELECT Имя FROM СТУДЕНТЫ[.Изучает. Предмет.Название  = 'СУБД ']
Результат - имена всех студентов, которые изучают СУБД

Отрабатываются одинаково эффективно, как в системах с симметричном доступом.
Вообще никаких проблем.

БредятинаА как это сделать в случае, когда целевой объект "запрятан" внутри другого "объекта". Мы даже не знаем о его существовании (а программист знает - на уровне системы хранения). Вы опять о Вашем мифическом "нафигаторе"? :) И какой опять "уровень" системы хранения? Нет никаких уровней. Есть схема предметной области в терминах классов и таблиц. "Программист" ее создал, "пользователь" может ее видеть.

Это я и имел в виду когда говорил, что бытие определяет сознание. У вас в голове уровни и Вы их везде видите. А их нет.

БредятинаПриведите хотя бы один пример выдумки. Пока, это Ваше высказывание не корректно. Отмазка, грубо говоря))) пожалуйста
- Непонятые мне уровни, которых нет.
- Дайте мне тынц где я "подтвердил, что делаю по Дейту", как Вы здесь утверждаете. Я к Дейту местами прислушиваюсь, но делаю все по себе. Если бы я "делал по Дейту", у меня получился бы "Tutorial D".
- Там же фраза "система типов выполняет роль отношений РМД". Система типов, описывающих предметную область, состоит из классов и таблиц. Она выполняет свою собственную роль. Не надо ничего "гипотетически предполагать"
- Ваш фирменный способ все переврать особенно ярко проявляется здесь...
БредятинаU-gene... я могу классы, которые есть множества объектов, использовать как домены таблиц (более строго, доменом являются множество ссылок на объекты класса)....
...опять по Дейту)) Он и не отрицает, что значением атрибута отношения может быть значение переменной отношения... Дайте тынц, где я до этого сказал, что у меня "объекты = значение переменной отношения"? Откуда Вы это взяли?
- И тд

БредятинаТо есть, МД верхнего уровня налицо. И почему же так сложно начать именно с ее описания??? Еще раз - уровней нет, в т.ч. верхнего. Откуда Вы взяли "налицо" его модель? Опять не понимаю, о чем Вы.

Бредятина... Ваши метания..., ... МД верхнего уровня..., прекратятся и мои метания. Я, либо внесу ее в перечень МД верхнего уровня, либо пойму, что это одна из уже описанных в нем моделей. Еще раз. Мне кажется , что моя система типов может выразить любую Вашу М. Я уже дал пример, где я одна и та же предметная область описывается двумя разными схемами. А если Вы с этим не согласны - то и фиг с ним. Думать о Ваших М мне действительно неинтересно. Участвовать в Ваших (и только Ваших) метаниях желания нет никакого.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286641
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
БредятинаPSV100А можно в двух словах подробнее о чём речь ? Или направить куда-то почитать.

13545785
и вся эта тема...
Выше дал ссылку на Дейта.

Спасибо.

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

Я хочу сказать, что Ваше отношение со стороны выглядит как-то так: всё, что не "MUMPS" - в топку.

БредятинаДа, только на первый. Вы говорите о программистах и СХОД, а я говорю о не программистах и СУБД.


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

P.S. Если Вы можете предоставить своё понимание концепции проектирования и моделирование от верхнего до нижнего уровня, некий "NewUML", со всей симметрией, лично я буду очень Вам благодарен.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286656
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаВся глава 25 (И8). В частности, стр. 1031.
Возьмем цитату оттуда
"Например, для рассматриваемого ранее отношения поставщиков и
деталей может возникнуть вопрос, содержатся ли объекты-поставщики в объектах-
деталях или наоборот. А может, верно и то и другое?"

А может и правда верно?:)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CLASS ПРЕДМЕТЫ
{
   ...
   изучаются SET OF
   {
      студент СТУДЕНТЫ
      ...
   } КEY студент
}

CLASS СТУДЕНТЫ
{
   
   ...
   изучает SET OF
   {
      предмет ПРЕДМЕТЫ
      ...
   } КEY предмет
}

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

БредятинаЧто значит "кажется"? Хороший вопрос! "Кажется" значит, что я про это думать не хочу. В том числе потому, что КМК спор в 14020991 ни о чем - каждый думает по своему. По мне, там Вы пытаетесь усложнить описание предметной области, которое Вам дает DirksDR. Моя система позволяет реализовать его описание напрямую.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286727
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneТо есть Вы считаете, что эти два класса и три отношения проще чем мои просто два класса? Сильно :)
Итак, есть только два класса:
К1) Документ-накладная (коллекция операций отгрузки, каждая из которых содержит ссылку на отгруженный товар)
К2) Товар
А отношений:
О1) Документ ("шапка" накладной)
О2) Операция отгрузки (запись в документе)
О3) Товар
на уровне РМД нет вообще. Это меняет дело! Я постепенно начинаю понимать))) Еще раз поясните на этом упрощенном примере почему именно Вы считаете, что:
"описав всего [два] класса, связанных ссылками, [вы считаете], что в системе тем самым определено существование [трех] отношений, где представлены данные объектов этих классов, и эти [три] отношения [программист] может использовать, вообще не задумываясь об случившемся переходе от объектов к отношениям".
U-geneО какой системе хранения Вы все время говорите? Объектные виды это способ представить данные для пользователя. Они генерятся динамически , когда пользователь обращается в систему за данными.
О реляционной, разумеется, в которой есть эти три отношения. Но, теперь, когда Вы сказали, что данные хранятся не в рамках трех переменных отношения (для П2), а в рамках двух классов, я прошу пояснить как именно организовано на логическом уровне хранение данных в MS SQL, которую Вы используете для хранения данных. Какие там (для П2) таблицы (раз термин "отношение" мы больше не используем).
U-geneНа примере Студентов и Предметов.

Схема

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CLASS ПРЕДМЕТЫ
{
   Название
   ...
}

CLASS СТУДЕНТЫ
{
   
   Имя
   ...
   изучает SET OF
   {
      предмет ПРЕДМЕТЫ
      ...
   } КEY предмет
}

Запрос, который вытаскивает данные по ссылке
Код: plaintext
SELECT Название FROM СТУДЕНТЫ[.Имя = 'Бредятина']. Изучает. Предмет
Результат - названия всех предметы, которые изучает Бредятина

Запрос, который вытаскивает данные "против" ссылке
Код: plaintext
SELECT Имя FROM СТУДЕНТЫ[.Изучает. Предмет.Название  = 'СУБД ']
Результат - имена всех студентов, которые изучают СУБД

Отрабатываются одинаково эффективно, как в системах с симметричном доступом.
Вообще никаких проблем.

)))
За исключением того, что пользователь не может получить вообще никаких данных. Вы же о программистах говорите. Но одно, пока, важно. Отсутствие симметричного доступа к данным Вы подтверждаете. Это хорошо))
U-geneВы опять о Вашем мифическом "нафигаторе"? :)
Нет, конечно. Я о системе управления базами данных. А Вы о системе хранения и обработки данных:)
U-geneИ какой опять "уровень" системы хранения? Нет никаких уровней. Есть схема предметной области в терминах классов и таблиц. "Программист" ее создал, "пользователь" может ее видеть. Это я и имел в виду когда говорил, что бытие определяет сознание. У вас в голове уровни и Вы их везде видите. А их нет.
Отношений нет - это я помню (не ясно только зачем Вы вообще о них говорили, раз их нет). И маппинга разумеется нет, раз нет отношений РМД. Совсем все прояснится, когда ы расскажете о таблицах MS SQL для П1 и П2.
U-geneПожалуйста:
- Непонятные мне "уровни", которых нет.
- Дайте мне тынц где я "подтвердил, что делаю по Дейту", как Вы здесь утверждаете. Я к Дейту местами прислушиваюсь, но делаю все по себе. Если бы я "делал по Дейту", у меня получился бы "Tutorial D".
- Там же фраза "система типов выполняет роль отношений РМД". Система типов, описывающих предметную область, состоит из классов и таблиц. Она выполняет свою собственную роль. Не надо ничего "гипотетически предполагать"
- Ваш фирменный способ все переврать особенно ярко проявляется здесь...
Бредятинапропущено...
...опять по Дейту)) Он и не отрицает, что значением атрибута отношения может быть значение переменной отношения... Дайте тынц, где я до этого сказал, что у меня "объекты = значение переменной отношения"? Откуда Вы это взяли?
- И тд

То, что я лжец, все уже хорошо знают. Вы сами ответите на все эти вопросы, когда поясните про таблицы на уровне реляционной системы. Так что, нельзя пока однозначно утверждать, что уровней нет. Тынц сейчас поищу... Система типов, описывающих предметную область, в смысле логической структуры, конечно же, аналогична системе отношений, описывающих предметную область. Это не очевидно?))
Я ни разу не сказал, что у Вас "объекты = значение переменной отношения". Вы просто вошли в раж, пытаясь найти хотя бы одну выдумку)))
U-geneЕще раз. Мне кажется , что моя система типов может выразить любую Вашу М. Я уже дал пример, где я одна и та же предметная область описывается двумя разными схемами.
Вы забыли про третью схему (не вложили Студентов в Предметы), и это не имеет никакого отношения к выражению любой М. Возьмите М2 (в третий раз прошу) и выразите для этого простого примера. Это, я думаю, не получится сделать, так как в Вашей системе на уровне структуры просто нет необходимых концепций.
U-geneА если Вы с этим не согласны - то и фиг с ним. Думать о Ваших М мне действительно неинтересно.
Это не соответствует действительности))
U-geneУчаствовать в Ваших (и только Ваших) метаниях желания нет никакого.
В своих метаниях участвовать вполне достаточно))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286776
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Спасибо. Но, по моему, у Вас какое-то предвзятое отношение. U-gene декларирует свой продукт как удобную оболочку (причём, по политическим причинам - это именно ООП) над конкретной моделью данных, при этом требуется минимум функционального ограничения питающей почвы. Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.
Заметьте, что я пишу по существу, а Вы - в целом. Если считать, что обсуждение вопроса по существу - это предвзятое отношение к вопросу, то да - у меня именно предвзятое, абсолютно предвзятое отношение к любому вопросу, связанному с теорией и проектированием БД.
PSV100Я не знаю, кто такой _мод и что он делает, но думаю, что он может вполне успешно применять своё нечто в своей практике.
Уточню. Но хотите знать? А ViPRos? Тоже не знаете? А хотите? Так читайте, например, эту тему:
13577413
PSV100Я хочу сказать, что Ваше отношение со стороны выглядит как-то так: всё, что не "MUMPS" - в топку.
А Вы ориентируйтесь на существо вопросов, а не на свои ощущения о моем отношении. Они ошибочны. И зачем вместо конкретных П1 и П2 Вы говорите о какой-то MUMPS - совершенно не понятно.
PSV100Вам U-gene конкретно сказал, что он здесь специально не рассматривает вопросы моделирования уровня выше, и тем более верхнего уровня. Он представил только маленький "программистский кусочек", и тут же требовать от него сразу не отходя от кассы полного решения проблем всего стека проектирования, моделирования, реализации и т.д., со всей сложностью и многообразия этого тяжёлого пласта, ну, как минимум, не корректно. Тем более в реальной жизни тем же программистам могут дать модель верхнего уровня от "хачу гламурную накладную, тута пусть будет название моей фирмы бальшими буквами, можно и цветочек здеся, а там типа чего мы продали..." до строгой формальной математической модели с верификацией. И, мне кажется, что Вы несколько зациклились на своём М-понимании мира. Вот здесь пытаются математическую модель выразить через когнитивную графику, пока толком ничего не получилось. Может быть Вы попробуете там всех научить, как адекватно отразить математическую сущность через М-реальность.
Какое мое М-понимание??? Проделанная мной работа по систематизации моделей, предлагаемых другими людьми - это вовсе не мое понимание, а объективное исследование. Вас это просто не интересует. И я это вполне уважаю. Почему собственно всех должны интересовать модели данных и архитектура "МД верхнего уровня+маппинг+РМД"?
PSV100P.S. Если Вы можете предоставить своё понимание концепции проектирования и моделирование от верхнего до нижнего уровня, некий "NewUML", со всей симметрией, лично я буду очень Вам благодарен.
Это не по существу темы. Есть П1 и П2. Если они Вас чем-то не устраивают, предложите U-gene П3. И этих П вполне достаточно, чтобы "предоставить своё понимание концепции проектирования и моделирование от верхнего до нижнего уровня, некий "NewUML", со всей симметрией".
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286808
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneНу a про иллюзию "несимметричного" доступа я уже сказал.
Неправда. Это не иллюзия. Даже в РМД, о чем умалчивает Дейт, доступ не симметричный. А я не умалчиваю, и это Вам почему-то не нравится:
13545785
U-gene"Кажется" значит, что я про это думать не хочу. В том числе потому, что КМК спор в 14020991 ни о чем - каждый думает по своему.
Там нет спора никакого. Там я объясняю концепцию связи. Если Вам ближе концепция "Мир состоит только из типов сущностей" (то есть, связей в нем нет), то так ясно и скажите.
13577413
U-geneПо мне, там Вы пытаетесь усложнить описание предметной области, которое Вам дает DirksDR. Моя система позволяет реализовать его описание напрямую.
Не серьезно. Я ничего не "пытаюсь усложнить", потому что не такой идиот, как здесь принято считать)) Чье-либо описание предметной области основано на модели , неужели это не очевидно? Вы реализуете конкретную модель напрямую. Это же очевидно))) Проблемы, которые Вы тем самым сохраняете, тоже очевидны. Я их изучаю, а не "пытаюсь усложнить"))
13254920
14026636
13632149
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38286839
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene- Дайте мне тынц где я "подтвердил, что делаю по Дейту"...
Меня изначально ввела в заблуждение фраза из
14367039
"и таблицы никуда не денутся, а мои классы могут использоваться как домены этих таблиц".
Подтверждаю, что Вы не подтверждали, что делаете по Дейту (в части первого серьезного заблуждения).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287076
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаU-geneТо есть Вы считаете, что эти два класса и три отношения проще чем мои просто два класса? Сильно :)
Итак, есть только два класса:
К1) Документ-накладная (коллекция операций отгрузки, каждая из которых содержит ссылку на отгруженный товар)
К2) Товар
А отношений:
О1) Документ ("шапка" накладной)
О2) Операция отгрузки (запись в документе)
О3) Товар
на уровне РМД нет вообще. Это меняет дело! Я постепенно начинаю понимать))) Еще раз поясните на этом упрощенном примере почему именно Вы считаете, что:
"описав всего [два] класса, связанных ссылками, [вы считаете], что в системе тем самым определено существование [трех] отношений, где представлены данные объектов этих классов, и эти [три] отношения [программист] может использовать, вообще не задумываясь об случившемся переходе от объектов к отношениям".

Всё, я опять сдаюсь. Не будет у меня для двух классов трех отношений. Откуда Вы эти три отношения взяли?

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

Система внутри (там где у меня MS SQL) тоже как-то организована. Но эта внутренняя организация, не имеет прямого отношения к тому, что будет сформировано на выходе. Она не равна выходу, как Вы себе это представляете, говоря по 3 отношения и про MS SQL. Про эту внутреннюю организацию в процессе пользования системой думать не надо, достаточно знать, что она оптимальна.

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

БредятинаОтсутствие симметричного доступа к данным Вы подтверждаете. Я показал, что отсутствие симметричной схемы не мешает получать данные во обоих направлениях. Какие то еще проблемы? А если это не согласуется с М - значит М идет нафиг. :)

БредятинаВозьмите М2... Спасибо большое. Я уже три раза отказывался. не хочу. Не надо :) Эта Ваша М, пусть у Вас и остается. Хотя...
Господа! Кому-нибудь нужна М...? Человек предлагает, а мне совсем не нужно :)

Бредятина 14020991 Там нет спора никакого. Там я объясняю концепцию связи. Если Вам ближе концепция... По ссылке человек просто хотел, что бы у связи был параметр. В моей системе так можно сделать, и никаких проблем не возникнет.
А Вы ему начали объяснять, что он неправильно думает. Если дело дойдет до дела, я думаю, клиент от Вас уйдет. :)

Бредятина Если Вам ближе концепция... Еще раз повторю, я не хочу думать о концепциях,и ни одна из них мне не ближе. Я про это сразу сказал, а Вы по-прежнему мне М втюхать пытаетесь. Успокойтесь наконец. :)

БредятинаЯ ничего не "пытаюсь усложнить", ... я лжец ...если что то на что то похоже, то это оно и есть :)

Ищите тынц.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287082
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Подтверждаю, что тынц, подтверждающий, что я не утверждал, найден :)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287245
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneВсё, я опять сдаюсь. Не будет у меня для двух классов трех отношений. Откуда Вы эти три отношения взяли?
Еще раз повторяю. В моей СУБД предметная область может описывается как угодно. Все команды для манипуляций с данными даются в терминах этой произвольной схемы данных. В том числе команды запросов данных, которые формируют данные на "выходе" системы. При этом форма представления данных на выходе всегда реляционная. И все это "ввод команд(+данные)" и "вывод данных" - один единственный уровень.
Отлично. Теперь понятно. (Всем остальным, наверное, все было понятно из презентации, а мне только теперь). Итак, Вы сделали буквально революцию. Не просто никаких уровней нет, но и никакой МД нет. Реляционной, в том числе. Так как нет первого аспекта МД - структурного! Далее, Вы это не раз подтвердите, выделяя большими буквами, жирным шрифтом и восклицательными знаками, что никакой М (модели данных, а я буквой М обозначаю именно модель данных) нет. Спасибо! Теперь буду в 5-ый раз смотреть презентацию, чтобы понять как Вам удается обходиться без модели данных на этапе проектирования БД (предполагаю, что и сам этот термин - проектирование БД - утрачивает свой исходный смысл при использовании Вашей системы. Мне это напоминает самоструктурирующиеся БД, которые разрабатывали коллеги из Санкт-Петербурга).
U-geneСистема внутри (там где у меня MS SQL) тоже как-то организована. Но эта внутренняя организация, не имеет прямого отношения к тому, что будет сформировано на выходе. Она не равна выходу, как Вы себе это представляете, говоря по 3 отношения и про MS SQL. Про эту внутреннюю организацию в процессе пользования системой думать не надо, достаточно знать, что она оптимальна.
Верю!
U-geneГоворя об отношениях на выходе, я специально использую фразу "определено существование" вместо "существуют". Это значит, что отношения могут существовать,что система может их вычислить, сформировать по запросу пользователя. И этих отношений очень-очень много, даже для двух классов.
Разумеется. Любая проекция и т.п. Практически, в любой системе результат запроса можно представить в виде отношения (таблицы). Для П2, например, такой:
23 12.05.2013 ООО "Весна" Шуруп 3 кг 110 руб.
23 12.05.2013 ООО "Весна" Гвоздь 2 кг 96 руб.
23 12.05.2013 ООО "Весна" Гайка 1 кг 70 руб.
...
В этом результате присутствуют свойства всех трех типов сущностей, о которых можно догадываться на основании схемы данных, не основанной ни на какой МД, и содержащей, тем не менее, два класса, один из которых включает коллекцию:)
[quot U-gene]Я показал, что отсутствие симметричной схемы не мешает получать данные во обоих направлениях. Какие то еще проблемы? А если это не согласуется с М - значит М идет нафиг. :)
РМД идет нафиг??? Она же модель:) Вы нервничаете, и это о многом говорит. Отсутствие симметричного доступа сильно осложнит реализацию СУБД, когда Вы до нее дойдете. Другое дело, что, вероятно, подобно тому, как Вас не интересуют модели данных, Вас так же не интересуют и интерактивные интерфейсы. И Вы просто будете утверждать, что они реализуются так же легко, как и любые модели данных. В Вашей системе.
U-geneЯ уже три раза отказывался. не хочу. Не надо :) Эта Ваша М, пусть у Вас и остается. Хотя...
Господа! Кому-нибудь нужна М...? Человек предлагает, а мне совсем не нужно :)
Я помню, что Вам не нужна никакая модель данных. Опять нервничаете, вероятно, чувствуя, что не все так гладко в произвольном описании предметной области без какой-либо М)))
U-geneПо ссылке человек просто хотел, что бы у связи был параметр. В моей системе так можно сделать, и никаких проблем не возникнет.
А Вы ему начали объяснять, что он неправильно думает. Если дело дойдет до дела, я думаю, клиент от Вас уйдет. :)
Вы демонстрируете непонимание концепции - это нормально)) Я же тоже, пока, не понимаю, как Вы обходитесь без МД. Не параметр, а свойство. Как у сущности. Человек хотел, чтобы связь была сущностью . Это же очевидно. Я вот пересматриваю Вашу презентацию, и перечитываю Ваши статьи, и спрашиваю Вас, если что-то не понятно. А Вы очень поверхностно рассуждаете, совершенно не вникая в суть вопроса. Связь - это не сущность. Нет у нее никаких свойств. Это совсем не сложно понять))
U-geneЕще раз повторю, я не хочу думать о концепциях,и ни одна из них мне не ближе. Я про это сразу сказал, а Вы по-прежнему мне М втюхать пытаетесь. Успокойтесь наконец. :)
Я не пытаюсь втюхать Вам модель, я просто, пока, не уверен, что никакой модели у Вас нет. Мне кажется, что в этой части Вы умышленно вводите в заблуждение. Буду смотреть презентацию, выписывать понятия - класс, свойство, ссылка, внешний ключ, и т.п. И постараюсь понять, что все эти понятия не являются понятиями какой-либо логической МД, и позволяют описывать предметную область, используя структурные элементы любой МД. Пока, я не вижу возможности это сделать. Но может быть, я прозевал какое-то важное понятие в презентации, которое позволит это сделать...
U-gene...если что то на что то похоже, то это оно и есть :)
Это проще всего - подтверждаю, что я лжец и идиот, чтобы больше не возвращаться (надеюсь) к этому вопросу.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287434
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и славненько.

Единственно, под М... я везде понимаю исключителььно Ваши М0-M5 (хотя где то я видел, как Вы про М6 говорили, так что подозреваю, что их больше может быть). То есть РМД, как формальная модель, никуда не идет. Система реляционная по определению - все данные представлены как множество отношений.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287447
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene,

для начала Вам необходимо здесь представить то, как Ваш проект работает внутри MSSQL. А точнее то, на каких таблицах всё построено. Естественно, частично, или лишь в двух словах концептуально. Т.е. показать, что в основе такая-то некая схема а-ля "EAV" (ключевую сущность), или всё на деревьях построено, при создании классов "Накладные" и "Товары" в БД создаются ли такие-то таблицы (шапки и строки накладных, товары), создаются ли такие-то отношения между ними и т.п. Затем Ваше "внутреннее хозяйство" можно сопоставить с принципами построения указанных "М-моделей" (или вдруг даже выяснить, что комплект не полон). Это даст возможность для согласования понимания сущности прикладных моделей, моделей данных, связь с РМД, какая возникает потребность в "маппинге" и т.д.
На всякий случай, подготовьтесь со своей терминологией. Например, понятие "REFERENCE" является "свойством" класса или его атрибутом (скорее, атрибутом, ибо даже отличается по синтаксису от свойств).
Это, конечно, не избавит Вас от того, что Вас продолжат учить, но даст толчок для финальной развязки.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287450
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бредятина,

спасибо за подборку "М-моделей" в одном компактном месте.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287530
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneНу и славненько. Единственно, под М... я везде понимаю исключительно Ваши М0-M5 (хотя где то я видел, как Вы про М6 говорили, так что подозреваю, что их больше может быть). То есть РМД, как формальная модель, никуда не идет. Система реляционная по определению - все данные представлены как множество отношений.
Не хорошо))) Введение мной обозначений вместо наименований моделей данных не делает их (модели) моими. Это все формальные модели верхнего уровня в архитектуре "модель верхнего уровня+маппинг+РМД", при которой данные хранятся именно в рамках отношений РМД, (а не в рамках, например, модели EAV, реализованной в реляционной системе). Например, М0 - это ER-модель. Даже Дейт не считает ее не формальной. С каких пор под реляционной понимается система, в которой нет хранимых отношений? А есть только временные отношения, как результаты запросов??? А как же нормализация, например (под которой часто понимают именно реляционную нормализацию)? И проектирование БД в целом?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287572
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene, поскольку пример из темы про МД верхнего уровня Вас не устроил, вместо него мы используем П1 из данной темы. Просмотрев презентацию еще раз, я пришел к выводу, что Вы используете модель _мод, М5, основанную на гипотезе, что [Мир состоит (только) из сущностей, обладающих свойствами]. Поскольку в М5 поддерживаются "системные первичные ключи" (или системные идентификаторы):

П1
Классы (вместо понятия Типы сущностей):
Студент {Фамилия, Имя, (Изучает, Предмет)}
Предмет {Наименование}

П2
Классы (вместо понятия Типы сущностей):
Документ {Дата, Организация-получатель, (Имеет, Отгрузка {(Относится к, Товар), Количество, Сумма}}
Товар {Наименование}

Но, Классы есть только при описании предметной области (и, извините, на уровне хранения данных). Любой запрос возвращает отношение РМД. Например, запрос, эквивалентный
SELECT * FROM Студент
вернет (считаем, что системные идентификаторы всегда есть в результате запроса):
1) если "Изучает" является значением некого атрибута результирующего отношения:

1 Иванов Петр Изучает 1 Алгебра
1 Иванов Петр Изучает 7 География
2 Петров Иван Изучает 1 Алгебра
2 Петров Иван Изучает 3 Химия

2) если "Изучает" не является значением некого атрибута результирующего отношения:

1 Иванов Петр 1 Алгебра
1 Иванов Петр 7 География
2 Петров Иван 1 Алгебра
2 Петров Иван 3 Химия

Пожалуйста, поправьте что не так.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38287777
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene[b]Господа! Кому-нибудь нужна М...?
Мне нужно чтобы на М3 пробок не было. Там за 7 км от МКАДА стало не возможно. Ну, если примите меры, буду благодарен.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38288584
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У М3 420 л.с., какие могут быть помехи ?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289123
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289178
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovPSV100Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.

Почему Вы подумали что это ORM?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289303
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятина...Например, М0 - это ER-модель. Даже Дейт не считает ее не формальной.?
Введение... (8-изд) стр 532
"Следует отметить, что семантическое моделирование имеет также несколько других названий, например, моделирование данных, ER-моделирование, моделирование сущностей и объектное моделирование. В настоящей книге по указанным ниже причинам предпочтение отдано термину семантическое моделирование (которое иногда называют также концептуальным моделированием).
Термин моделирование данных не подходит , поскольку он конфликтует со сложившимся ранее определением термина модель данных, который обозначает формальную систему наподобие реляционной модели ..."
БредятинаС каких пор под реляционной понимается система, в которой нет хранимых отношений? А есть только временные отношения, как результаты запросов???
стр 126
1) "Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных (т.е. переменных отношения — relvar), значениями которых являются отношения". И все. Где то рядом идут рассуждения о базовых и производных переменных отношений, но нигде нет формального требования, что без базовых переменных не обойтись.
2) У меня хранимые отношения есть. Все значения атрибутов объектов (я называю из компонентами объектов) - это, по Дейту, "типы, допускающие реляционное присваивание". Как только я реализую компоенент как хранимый, можно смело говорить о существовании хранимых отношений, значения которого как-то характеризует отдельные экземпляры какой-то сущности объекты какого-то класса. Причем это происходит в той проекции, где я описываю предметную область (эта проекция не является реляционной).А дальше система, пользуясь свойствами реляционной модели, собирает эти значение в большие отношения, которые как то характеризуют множества экземпляров.
Бредятина А как же нормализация, например (под которой часто понимают именно реляционную нормализацию)? И проектирование БД в целом?
Про проектирование было здесь 14390609 . А нормализация не есть вопрос формализма. Даже в первой НФ отношения есть отношения.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289307
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаПросмотрев презентацию еще раз, я пришел к выводу, что Вы используете модель _мод, М5, основанную на гипотезе, что [Мир состоит (только) из сущностей, обладающих свойствами]. Я в десятый раз повторяю, что из средств описания предметной области в прототипе (и в презентации) реализованы только классы. Поэтому Вы и видите М5. Таблиц в презентации нет( а для меня они очевидны). Были бы таблицы, Вы еще что-нибудь увидели.
Бредятина...SELECT * FROM Студент... Про звездочки, применительно к классам,я думаю. Это КМК, не является ни вопросм М, ни формальным вопросом; чисто языковая вещь,хотя и привычная.

В любом случае Бредятина ...если "Изучает" является значением некого атрибута результирующего... меня поразило. "Изучает" - это имя в схеме данных. Оно в запросе может появиться, и, соответственно, в заголовках результат запроса.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289321
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovPSV100Естественно, как и у каждой технологии есть свои плюсы, так и недостатки.В основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.

1) Вот из-за таких вопросов я и отказываюсь лезть на концептуальный уровень. Взамен я предлагаю систему, где есть и классы и таблицы, и которую каждый может использовать как хочет. Не нравятся классы - пользуйтесь только таблицами. А кому-то только классы нравятся. Ну а кто-нибудь захочет изобразить комбинированную схему.
2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности. А я думаю, что нормализация, как все остальное, что проходит в рамках реляционной модели, к этим непонятным и неопределенным сущностям (и др. концептуальным вещам) отношения вообще не имеет. Не бывает отдельно строк накладной и заголовка. И, нормализовав данные накладной, можно продолжать думать о ней, как о едином целом. А в RxO вы можете эту мысль реализовать.
3) Опять ORM. Я даже пример 14390674 дал, что бы показать что RxO - это не ORM, что в RxO классы рядом и вместе с таблицами, что это одна система, а не попытка насильно поженить две разные. Вот, теперь человека перепугали.:)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289336
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovВ основе всех ORM-ов (RxO - совсем не исключение) лежит концептуальная ошибка.
Как пример: нормализация базы - декомпозиция сущностей и (до)определение связей, прямо противоречит принципам инкапсуляции.

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

Здесь коллега Бредятина давал ссылку на своё понимание сути ORM, т.е. если "модель данных должна быть одна и та же на концептуальном и логическом уровнях" - то и нет потребности в ORM и подобных увязках.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289337
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene,

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

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

В этом случае, проблема в RxO, фактически, переносится автоматом. Поскольку через классы задают некую прикладную модель, при этом же она выражает и как бы конечную модель (логическую) в БД, то часто классы "накладных" на самом деле вынужденны будут задавать как-то так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE CLASS Накладная
( 	Номер      STRING,
	Дата  	   DATETIME,
	Поставщик  INTEGER,
	...
	Содержимое SET OF
	( 	
		Дата  	   DATETIME,
		Поставщик  INTEGER,
		Товар      INTEGER,
		...
	)
);


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

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

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

Вы оценивали подобные проблемы, не приведёт ли это к тому, что часто будут вынуждены использовать Ваши планируемые таблицы, вместо классов?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38289421
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100"модель данных должна быть одна и та же на концептуальном и логическом уровнях" - то и нет потребности .....
То и нет потребности в разных уровнях: раз модель одна и та же, то они (уровни) ни чем и не отличаются.

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

Но не очевидно, что это и недостаток во всех отношениях.
Специализированные в своих областях (в данном случае уровнях), часто лучше комбайна в этих областях.
В UML мы же с удовольствием юзаем разные диаграммы.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290199
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneВведение... (8-изд) стр 532
"Следует отметить, что семантическое моделирование имеет также несколько других названий, например, моделирование данных, ER-моделирование, моделирование сущностей и объектное моделирование. В настоящей книге по указанным ниже причинам предпочтение отдано термину семантическое моделирование (которое иногда называют также концептуальным моделированием).
Термин моделирование данных не подходит , поскольку он конфликтует со сложившимся ранее определением термина модель данных, который обозначает формальную систему наподобие реляционной модели ..."
И снова обращаю Ваше внимание на недопустимость столь поверхностного отношения))
Я детально изучаю Ваши труды, а Вы даже к Дейту относитесь пренебрежительно:
"Но при более внимательном чтении работы [14.6] можно предположить, что ER-модель действительно является моделью данных, но такой, которая представляет собой лишь небольшое дополнение к реляционной модели...".
А как же! Конечно, небольшое. Но достаточное для необходимости в архитектуре "модель верхнего уровня+маппинг+РМД". Но к Вашей системе это не относится, так как ни РМД (для перманентных данных см. далее), ни маппинга у Вас нет. Вы, в отличие от ViPRos, не поленились (он аргументировал использование такой архитектуры желанием использовать готовую инфраструктуру на уровне хранения и обработки данных).
U-geneстр 126
1) "Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных (т.е. переменных отношения — relvar), значениями которых являются отношения". И все. Где то рядом идут рассуждения о базовых и производных переменных отношений, но нигде нет формального требования, что без базовых переменных не обойтись.
Очень плохо. Опять(((
Стр. 51 - относится к ЛЮБОЙ БД, хоть реляционной, хоть не реляционной:
"... данные в базе являются перманентными , поскольку после того, как они были приняты средствами СУБД для помещения в базу, их последующее удаление возможно лишь при использовании соответствующего явного запроса к базе данных , но не в результате какого-либо побочного эффекта от выполнения некоторой программы...
База данных - это некоторый набор перманентных (постоянно хранимых) данных..."
U-gene2) У меня хранимые отношения есть. Все значения атрибутов объектов (я называю из компонентами объектов) - это, по Дейту, "типы, допускающие реляционное присваивание". Как только я реализую компоенент как хранимый, можно смело говорить о существовании хранимых отношений, значения которого как-то характеризует отдельные экземпляры какой-то сущности объекты какого-то класса. Причем это происходит в той проекции, где я описываю предметную область (эта проекция не является реляционной). А дальше система, пользуясь свойствами реляционной модели, собирает эти значение в большие отношения, которые как то характеризуют множества экземпляров.
Буду вот так вытягивать информацию и дальше, чтобы разобраться наконец-то какая у Вас архитектура - с маппингом и РМД или нет:)
U-geneПро проектирование было здесь 14390609 . А нормализация не есть вопрос формализма. Даже в первой НФ отношения есть отношения.
Что было про проектирование??? Обоснование, что проектирование БД осуществляется без МД?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290240
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ в десятый раз повторяю, что из средств описания предметной области в прототипе (и в презентации) реализованы только классы. Поэтому Вы и видите М5. Таблиц в презентации нет( а для меня они очевидны). Были бы таблицы, Вы еще что-нибудь увидели.
Не корректно. И не честно. Давайте без "если бы". Я очень четко написал, что вместо термина "Тип сущности" Вы используете термин "Класс". Пожалуйста, дайте замечанию по существу по рассмотренному мной примеру. Я же большую работу вместо Вас провожу, чтобы сделать понятными Ваши разработки...
U-geneПро звездочки, применительно к классам,я думаю. Это КМК, не является ни вопросм М, ни формальным вопросом; чисто языковая вещь,хотя и привычная.
Прокомментируйте по существу. Звездочка не влияет на существо, надеюсь.
U-geneВ любом случае Бредятина ...если "Изучает" является значением некого атрибута результирующего... меня поразило. "Изучает" - это имя в схеме данных. Оно в запросе может появиться, и, соответственно, в заголовках результат запроса.
Это зря))) Однако. меня устраивает. Итак, верный результат без "Изучает". В остальном все правильно? Прежде, чем говорить откуда берется название производного отношения...
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290252
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности. А я думаю, что нормализация, как все остальное, что проходит в рамках реляционной модели, к этим непонятным и неопределенным сущностям (и др. концептуальным вещам) отношения вообще не имеет.
Просто фантастика)) При описании РМД у Кодда сущности на каждом шагу. Даже в формальных определениях!:
" Rule 1 (entity integrity): No primary key value of a base relation is allowed to be null or to have a null component"
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290259
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Сделаю предположение, что на нижнем уровне лежит "чистая" РМД, полная "sql-трансформация" в лоб. Условно, пусть те же классы "Накладные" и "Товары" трансформируются в соответствующие таблицы sql-сервера "Шапки накладных", "Их строки", "Товары".
Я верю U-gene, что это не так.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290725
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene,

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

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

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

Теперь я попробую сделать модель в RxO для подобного случая. Мне нужен базовый класс "Документы", и два наследника: "Накладные" и "Акты". Т.е. предполагается, как только выписывается "накладная" она сразу же становится "общим документом", который есть основа для "акта" (или, фактически, это один и тот же документ). Эти "общие документы" в реальности применяются для ряда взаимосвязанных подзадач (не только "накладные" и "акты"), соответственно требуется или закладывается возможность организовать "документы" как общее хранилище.
Таким образом, мне нужна такая вот иерархия:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE CLASS Документы
(   Тип        INTEGER,
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

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

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


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

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

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

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


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

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

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

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

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

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

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


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


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

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

Спасибо.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290797
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МурычПочему Вы подумали что это ORM?Пока автор использует в качестве хранилища реляционную СУБД - это ORM.
Реализует нативное хранилище объектов - можно будет оценить содеянное.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290805
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene1) Вот из-за таких вопросов я и отказываюсь лезть на концептуальный уровень.Напрасно.Взамен я предлагаю систему, где есть и классы и таблицы"Генетики создали гибрид капусты и редьки. Проблема в том, что у него листья редьки и корень капусты"2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности.В процессе нормализации устраняется избыточность данных и определяются связи.Не бывает отдельно строк накладной и заголовка.Это вас кто-то обманул.И, нормализовав данные накладной, можно продолжать думать о ней, как о едином целом. А в RxO вы можете эту мысль реализовать.Угу. Как минимум двумя способами - с денормализацией и без.это одна система, а не попытка насильно поженить две разныеЯ посмотрю на ваш оптимизм, когда ваша система встанет в промышленную эксплуатацию на реальных объёмах данных.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290810
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100И в чём же именно концептуальная ошибка?В способе стыковки.
Т.к. программистам "сложно" работать с DML - изобретаются различные костыли, отображающие объекты на схему базы.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290822
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vadiminfoPSV100"модель данных должна быть одна и та же на концептуальном и логическом уровнях" - то и нет потребности .....
То и нет потребности в разных уровнях: раз модель одна и та же, то они (уровни) ни чем и не отличаются.

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

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

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

P.S. Ну, лично я UML не очень-то с удовольствием юзаю, или частично, но это и мои личные тараканы, не о них речь.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290839
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovPSV100И в чём же именно концептуальная ошибка?В способе стыковки.
Т.к. программистам "сложно" работать с DML - изобретаются различные костыли, отображающие объекты на схему базы.

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

Впрочем, здесь опять путаница в терминологии, я не теоретик. Думаю, что здесь найдутся те, кто сможет все термины разложить по полочкам.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290870
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.Да, ORM - ошибка природы.
Вас удивляет, что ошибка существуют и вполне успешно? Ну так не удивляйтесь - это вполне нормально.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38290901
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100
тип моделей может быть один и тот же. .
Это означает, что может быть и разным.

Т.е. в любом случае мыстль "модель данных должна быть одна и та же на концептуальном и логическом уровнях", скорее всего, связана с какой-то идеей впарить что РБД не БД, или тому подобной ахинеей.
Поскольку де мол БД не дложна, а РБД так поступает.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291043
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vadiminfoPSV100 тип моделей может быть один и тот же. .
Это означает, что может быть и разным.

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

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

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

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

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


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


Логическая модель у нас в клиентском приложении. Представим его на псевдокоде:
Код: sql
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.
-- тип "структура", отражающий конкретные "накладные":
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. SidorovPSV100Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.Да, ORM - ошибка природы.
Вас удивляет, что ошибка существуют и вполне успешно? Ну так не удивляйтесь - это вполне нормально.

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

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

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

Именно эти вещи я имел в виду, когда говорил, что "бытиё определяет сознание". Кстати, всегда думал, что разница между программистами и спецами по БД высосана из пальца. Оказывается, я ошибался.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291111
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100U-gene,

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

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

В этом случае, проблема в RxO, фактически, переносится автоматом. Поскольку через классы задают некую прикладную модель, при этом же она выражает и как бы конечную модель (логическую) в БД, то часто классы "накладных" на самом деле вынужденны будут задавать как-то так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE CLASS Накладная
( 	Номер      STRING,
	Дата  	   DATETIME,
	Поставщик  INTEGER,
	...
	Содержимое SET OF
	( 	
		Дата  	   DATETIME,
		Поставщик  INTEGER,
		Товар      INTEGER,
		...
	)
);


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

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

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

Вы оценивали подобные проблемы, не приведёт ли это к тому, что часто будут вынуждены использовать Ваши планируемые таблицы, вместо классов? Забудьте про EAV (чур меня). Ваша накладная в лоб отобразится в две таблицы. Думаю, что в реальной практике такое дублирование (прям один-в-один, как Вы изобразили) тоже может использоваться с теми же целями.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291121
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE CLASS Документы
(   Тип        INTEGER,
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

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

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


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

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

Всё. Реализации компонентов и методов тоже наследуются, пока не переопределим. Значит и в объектах классов "Акты" и "Документы" эти компоненты тоже будут хранимыми. Ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели" :).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291263
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-geneЗабудьте про EAV (чур меня). Ваша накладная в лоб отобразится в две таблицы. Думаю, что в реальной практике такое дублирование (прям один-в-один, как Вы изобразили) тоже может использоваться с теми же целями.

Уже хорошо, что внизу появились интуитивно-адекватные таблицы.

Но, всё таки, вынужден обратить внимание. Пусть "накладная" задана в виде "прикладной модели пользователя":
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Накладная:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...
	Содержимое:
		Товар  => INTEGER
		Цена   => CURRENCY
		Сумма  => CURRENCY
		...


В каком-нибудь ООП-языке для программы эту модель могут определить как-то так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
struct Накладная
{ 	Номер:      STRING;
	Дата:  	    DATETIME;
	Поставщик:  INTEGER;
	...
	struct Содержимое
	{ 	
		Товар:   INTEGER;
		Цена:    CURRENCY;
		Сумма:   CURRENCY;
		...
	}
};


Внутри RxO вынуждены будут задать так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
CREATE CLASS Накладная
( 	Номер      STRING,
	Дата  	   DATETIME,
	Поставщик  INTEGER,
	...
	Содержимое SET OF
	( 	
		Товар:   INTEGER,
		Цена:    CURRENCY,
		Сумма:   CURRENCY,

		-- а эти данные вынужденны дублировать:
		Дата  	   DATETIME,
		Поставщик  INTEGER,
		...
	)
);


Иными словами, в RxO классы выражают прикладные сущности и, получается, одновременно и физическую организацию данных. О возможных последствиях был смежный пост.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291280
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-geneОк. А дальше все гораздо проще. Где-нибудь делаем

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


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


Странно, если есть какое-то "STORED", значит же есть и какое-то хоронилище. Ну да ладно. То, что не нужно ни о чём думать - мне нравится, никаких хранилищ, никакой "физики" и т.д. - это же мечта.

Попробую построить проект согласно такой идеологии RxO. Напомню, требуется реализовать обработку двух элементарных документов, представим их в "модели пользователя":
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Накладная на отгрузку:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...


Приходный акт:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...


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

Итак, приступим. Согласно методике RxO нам достаточно выразить прикладные сущности:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
CREATE CLASS Документы
(   
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

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

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

-- и задействуем ключевой "STORED":
ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.



Теперь на "производстве" создают накладную:

NEW Накладные WITH SET
.Номер := "A-01"
.Дата := to_date("08.06.2013")
.Поставщик := 15;
...

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

SELECT .Номер, .Дата, .Поставщик, ... FROM Акты

Ура! Акт появился!

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

Код: sql
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.
-- теперь общие документы такие:
CREATE CLASS Заготовка_для_документов
(   
    Номер      STRING,
    Дата       DATETIME,
    ...
);

-- ещё одна заготовка
CREATE CLASS Внешние_документы EXTEND Заготовка_для_документов
(   
    Поставщик  INTEGER,
    ...
);

-- и ещё
CREATE CLASS Внутренние_документы EXTEND Заготовка_для_документов
(   
    Подразделение  INTEGER,
    ...
);

-- накладные теперь такие
CREATE CLASS Накладные EXTEND Внешние_документы
(
	...
);


-- новые акты инвентаризации
CREATE CLASS Акты_инвентаризации EXTEND Внутренние_документы
(
	...
);


-- теперь у нас есть "Приходные акты", возникающие
-- из "накладных" и "актов инвентаризации".
--
-- Ключевой момент: теперь фиг поймёшь, от какого предка наследоваться,
-- я уже для простоты взял "Внешние_документы", с расчётом "совместимости"
-- разных типов документов, которые составляют сущность этих "Приходные актов".
-- А так, вынуждены организовать иерархию, указанную выше, ещё муторнее.
--
-- Также вынужденны иметь свойство "Источник",
-- которое указывает или на "Поставщика" или на "Подразделение",
-- что требует отдельной его реализации как "вычислимое",
-- для простоты этот момент опускаем (я толком и не понимаю как)
CREATE CLASS Приходные_акты EXTEND Внешние_документы
(
    Источник  INTEGER,
    ...
);

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

ALTER Заготовка_для_документов REALIZE (Номер, Дата, ...) AS STORED;

ALTER Внешние_документы REALIZE (Поставщик, ...) AS STORED;

ALTER Внутренние_документы REALIZE (Подразделение, ...) AS STORED;


Наконец-то наваяли, и удовлетворили начальство.

Теперь в "производстве":

NEW Накладные WITH SET
.Номер := "A-01"
.Дата := to_date("08.06.2013")
.Поставщик := 15;
...


Где-то сделали акт инвентаризации:

NEW Акты_инвентаризации WITH SET
.Номер := "И-01"
.Дата := to_date("08.06.2013")
.Подразделение := 234;
...


Теперь на складе делают выборку документов:

SELECT .Номер, .Дата, .Источник, ... FROM Приходные_акты


Опять ура! Все документы на месте. Работу сдали.


Я правильно всё спроектировал? (согласно идеологии RxO: "ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели")

Документы на складе будут появляться? (лично я уверен что нет. И я так и не смог решить эту задачу, с учётом того, чтобы не было нигде никакого дублирования данных, всё везде оптимально, красивенько, и прикладная модель причёсана)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291354
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100U-geneОк. А дальше все гораздо проще. Где-нибудь делаем

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


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


Странно, если есть какое-то "STORED", значит же есть и какое-то хоронилище. Ну да ладно. То, что не нужно ни о чём думать - мне нравится, никаких хранилищ, никакой "физики" и т.д. - это же мечта.

Попробую построить проект согласно такой идеологии RxO. Напомню, требуется реализовать обработку двух элементарных документов, представим их в "модели пользователя":
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Накладная на отгрузку:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...


Приходный акт:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...


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

Итак, приступим. Согласно методике RxO нам достаточно выразить прикладные сущности:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
CREATE CLASS Документы
(   
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

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

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

-- и задействуем ключевой "STORED":
ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.



Теперь на "производстве" создают накладную:

NEW Накладные WITH SET
.Номер := "A-01"
.Дата := to_date("08.06.2013")
.Поставщик := 15;
...

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

SELECT .Номер, .Дата, .Поставщик, ... FROM Акты

Ура! Акт появился!

Нет, так ракеты не летают.

Классы Акты и Накладные - разные подклассы (непересекающиеся подмножества) общего суперкласса Документы. Новая Накладная будет видна как объект класса Документы, но в множестве Акты она не появится. Сели мы создадим просто Документ, он из подклассов виден не будет.

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

Дальше, мне показалось, то же самое.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291592
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.
ORM (где под О понимается семантический аспект, в первую очередь) - объективная необходимость. Так как прямое использование РМД невозможно. Это не значит, вероятно, что РМД - ошибка природы. Собственно, U-gene и доказывает, что РМД - не ошибка, обходясь, как он уверяет, без ORM.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291594
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoPSV100 тип моделей может быть один и тот же. .
Это означает, что может быть и разным.

Т.е. в любом случае мыстль "модель данных должна быть одна и та же на концептуальном и логическом уровнях", скорее всего, связана с какой-то идеей впарить что РБД не БД, или тому подобной ахинеей.
Поскольку де мол БД не дложна, а РБД так поступает.
Мы же уже договорились, что я - идиот и впариваю ахинею))
Однако, то, что семантически развитая логическая МД может использоваться, как концептуальная - это просто факт, к сожалению. То есть, идиоты, иногда,оказываются правы))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291598
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Давая ссылку на цитату от коллеги Бредятина где-то выше в своём исходном посте, я лишь подразумевал только одно предложение из всего контекста, которое я вспомнил тогда, уже ночью строчив свой текст. Это следующий тезис: "модель данных должна быть одна и та же на концептуальном и логическом уровнях". Затем Вы сделали уточнение на счёт не одной модели, а об одном типе моделей. В результате в моём сознании эта фраза трансформировалась (а изначально я так и подразумевал) в понятие того, что для разных уровней (логического, выражающего прикладную область, и физического, отражающего реальное устройство данных) желательно иметь модели схожего или близкого типа, чтобы было меньше проблем со всякой трансформацией и прочими перегонялками данных по всем фронтам.
Вы напрасно добавили физический уровень. Ведь речь шла только о проектировании (на основе МД в первом смысле, по дейту) и использовании МД во втором смысле, по Дейту (независимо от физической реализации данных). При использовании "реляционных систем" архитектура "модель верхнего уровня+маппинг+РМД" неизбежна. Если только не заменить РМД на модель EAV или использовать разработку U-gene))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291602
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЯ везде использую хорошо известный термин "трансляция" и считаю, что люди меня понимают(как правило, так оно и есть).Но, оказывается, некоторые настолько погрязли в маппинге, что ничего другого не видят. Например Бредятина. И здесь, и в других местах я неоднократно объяснял ему, что речь идет о трансляции ОО-команд, а он считает, что всего лишь игра слов, и, поэтому, тут же начинал говорить про "МД верхнего уровня+маппинг+РМД".
Заблуждение. Причем, как мне кажется, умышленное)) Никто здесь Вас не поддерживает, как я. И эта поддержка заключается в том, чтобы детально разобраться, и показать, что маппинга (так же хорошо известный термин) по всем трем аспектам (структура+ОЦ+манипулирование) в Вашей системе нет в принципе. Поэтому, не стоит философствовать говорите по существу, используя удобные для Вас термины.
U-geneКстати, всегда думал, что ... разница между программистами и спецами по БД высосана из пальца. Оказывается, я ошибался.
Это точно. Между ними непреодолимая пропасть))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291605
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Итак, мы рассматриваем простые примеры. Причем, вместо очевидной (пока) для системы U-gene гипотезы "Мир состоит (только) из сущностей, обладающих свойствами", и понятия Тип сущности, мы договорились (пока) не рассматривать никакие гипотезы об окружающем мире (и моделируемых предметных областях, в частности), и заменили Тип сущности на Класс:

П1
Классы:
Студент {Фамилия, Имя, (Изучает, Предмет)}
Предмет {Наименование}

П2
Классы:
Документ {Дата, Организация-получатель, (Имеет, Отгрузка {(Относится к, Товар), Количество, Сумма}}
Товар {Наименование}

Но, Классы существуют только при описании предметной области (и, извините, на уровне хранения данных). Любой запрос возвращает отношение РМД, но не класс . Например, запрос, эквивалентный
SELECT * FROM Студент
вернет (считаем, что системные идентификаторы всегда есть в результате запроса):

1 Иванов Петр 1 Алгебра
1 Иванов Петр 7 География
2 Петров Иван 1 Алгебра
2 Петров Иван 3 Химия

U-gene, пожалуйста, поправьте, если что не так.[/quot]
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291661
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятина,

Нет, пока с терминами не разберемся, дальше разговаривать смысла нет.

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

Трансляция подразумевает преобразование команд , управляющих одной единственной системой данных.

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

Если Вы согласны с такой трактовкой этих двух терминов, то можно будет продолжить.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291703
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneНет, пока с терминами не разберемся, дальше разговаривать смысла нет.
Разумеется! Это же очевидно.
U-geneИтак "маппинг" подразумевает обмен данными между двумя системами данных и выполняет необходимое для обмена преобразование структур этих данных.
Уточняю. Первая система данных - это линейная память, используемая программой написанной на ОО языке. Вторая система данных - реляционная БД.
Отлично. Уточните: данные хранятся в реляционной БД в каком виде? В реляционном? Атрибуты отношений - это свойства "неизвестно чего" (так как Вы запрещаете использовать, например, такие термины как "сущность" или связь")? Или еще и термин "свойство" мы тоже не можем использовать?
U-geneТрансляция подразумевает преобразование команд , управляющих одной единственной системой данных.
В этом смысле, действия, выполняемые RxO аналогичны действиям, которые выполняет OO компилятор в момент создания ОО программы. Конечно, RxO учитывает специфику исполняющей машины, что проявляется, например, в тех же типах атрибутов объекта, которые есть "значения типов, допускающих реляционное присваивание", и в очень многих других местах, в т.ч. в том факте, что мы уходим от программы к декларативным командам. Никому в голову не придет сказать, что существует какие-то "концептуальные ошибки" или "несостыковки" между транслятором и целевой машиной.
Если Вы согласны с такой трактовкой этих двух терминов, то можно будет продолжить.
Конечно! Согласен! Я уже продолжил - см. вопрос выше.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291783
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятина... я - ... впариваю ахинею))

Еще бы.

БредятинаОднако, то, что семантически развитая логическая МД может использоваться, как концептуальная - это просто факт, к сожалению.
Если эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха), а тем более и ER , судя по всему, лучшая на концептуальном, то хоть "семантически развитая" и может, но кому это надо.
Таких семантически развитых предлагалось в свое время. Так и остались чисто академическими.
Т.е. не должна БД использовать такую "семантически развитая логическая МД", если она хуже на логическом уровне РМД, скорее всего.
"Я могу есть только лучший обед. Я не могу есть гадкого обеда" (С) Гоголь "Хлестаков"
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38291937
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoЕще бы.
Что РМД - ошибка природы? Быстро согласились, на этот раз))
vadiminfoЕсли эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха),
Факт, что это не так. На логическом уровне РМД уступает по всем аспектам. А эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))
vadiminfoа тем более и ER , судя по всему, лучшая на концептуальном, то хоть "семантически развитая" и может, но кому это надо.
Тем, кто впаривает РМД, конечно, не надо)) А те, кому впаривают, просто ни о чем не знают.
vadiminfoТаких семантически развитых предлагалось в свое время. Так и остались чисто академическими.
Говорите конкретно, какие МД верхнего уровня Вы хотите добавить к М0-М5. Что там предлагалось, и в какое время))
vadiminfoТ.е. не должна БД использовать такую "семантически развитая логическая МД", если она хуже на логическом уровне РМД, скорее всего.
Не скорее всего, а абсолютно точно.
vadiminfo"Я могу есть только лучший обед. Я не могу есть гадкого обеда" (С) Гоголь "Хлестаков"
Который врал, периодически. Впаривал РМД, своего рода, так сказать))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292023
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаФакт, что это не так. На логическом уровне РМД уступает по всем аспектам. А эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))

Ее не "впаривают", просто альтернатив нет, в принципе.
Для РМД есть конкретная реализация - SQL.
Которая (реализация) с одной стороны проста, с другой достаточно мощная и гибкая, что покрывает почти весь класс задач.

<:o)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292033
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятина Быстро согласились, на этот раз))

Почему на это раз? Давно согласен с этим:


Бредятина Мы же уже договорились, что я - идиот и впариваю ахинею))



БредятинаФакт, что это не так.
На логическом уровне РМД уступает по всем аспектам.
Угу. Только тем кто 30 лет назад ошибся выбрав не РМД, теперь рассуждать про аспекты. Смешно.

БредятинаА эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))

Да. Да. Ну где им до Вашего образования? Даже ошибок у Дейта им не удается найти.

Так или иначе:
Бредятина"модель данных должна быть одна и та же на концептуальном и логическом уровнях" -


Неуклюжая попытка абсолютизировать мелкий недотаток (если это вообще недостаток). Так как с любым образованием ясно, что лучшее из лучшего на на любом уровне выбрать лучший для этих уровней тип МД, если он даже ни для каких других уровней или чего либо вообще другого не подходит.

РМД может быть по производительности могут где-то потеснить. Но по логике пока что не видно ничего.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292043
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulЕе не "впаривают", просто альтернатив нет, в принципе.
И чтобы впаривать вот так и учат в университетах. Вот, видите, и Вас так научили))
mad_nazgulДля РМД есть конкретная реализация - SQL.
Бесполезная реализация.
14026636
За 30 лет нашел лишь одно ясное применение алгебре, когда она органично сочетается с семантикой.
mad_nazgulКоторая (реализация) с одной стороны проста, с другой достаточно мощная и гибкая, что покрывает почти весь класс задач.
Заблуждение. Практически, ни одной задачи)) Поэтому и приходится применять архитектуру "модель+маппинг+РМД", часто даже не РМД, а EAV.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292048
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoПочему на это раз? Давно согласен с этим
Что РМД - ошибка природы? Это новость для меня))
vadiminfoУгу. Только тем кто 30 лет назад ошибся выбрав не РМД, теперь рассуждать про аспекты. Смешно.
Опять ошибка. Я выбрал именно РМД. Поэтому и знаю ее лучше, чем кто-либо другой. Убедился в непреодолимости недостатков, связанных с невозможностью реализовать основные принципы БД.
vadiminfoДа. Да. Ну где им до Вашего образования?
Не "им", а "вам".
vadiminfoДаже ошибок у Дейта им не удается найти.
А их не нужно искать. Они лежат на поверхности. "Они" их просто умалчивают, чтобы впаривать))
vadiminfoНеуклюжая попытка абсолютизировать мелкий недотаток (если это вообще недостаток). Так как с любым образованием ясно, что лучшее из лучшего на на любом уровне выбрать лучший для этих уровней тип МД, если он даже ни для каких других уровней или чего либо вообще другого не подходит.
То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Не нужны никакие попытки, чтобы что-то абсолютизировать. Вернитесь к теме. наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
vadiminfoРМД может быть по производительности могут где-то потеснить. Но по логике пока что не видно ничего.
Конечно, конечно. Так ведь научили))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292101
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Любой может убедиться, что там было не про мечту всей жизни ЧАЛа:

БредятинаЧто РМД - ошибка природы?

А про реальное какие-то положение вещей:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))


А других в неправде упрекает. Хорош правдист. Нечего сказать.



БредятинаПоэтому и знаю ее лучше, чем кто-либо другой.
Оно и видно. "Знание" так и прет.


БредятинаТо, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно))

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



БредятинаКонечно, конечно. Так ведь научили))

Да уж спасибо, что не как ЧАЛа научили.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292183
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бредятина Бесполезная реализация.
14026636

полезная. и вы это увидите когда поработаете более года. алгоритмы обработки OLTP транзакций меняются с годами и ростом данных. данные в OLTP растут экспоненциально, системы типа MUPS, не способные подгонять алгоритмы обработки данных на лету ушли на свалку истории безвозвратно.
имхо после разочарования ИТ индустрии в ОО подходах, РМД будет искать варианты замены процедурных расширений на какую-то декларативную хрень.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292304
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!полезная. и вы это увидите когда поработаете более года. алгоритмы обработки OLTP транзакций меняются с годами и ростом данных. данные в OLTP растут экспоненциально, системы типа MUPS, не способные подгонять алгоритмы обработки данных на лету ушли на свалку истории безвозвратно.
Наивно)) Мягко говоря. Поработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой создания и эксплуатации БД, в том числе, именно потому что легкость "подгонки алгоритмов" превосходит "реляционные системы" настолько, что даже сравнивать не имеет смысла.
Yo.!имхо после разочарования ИТ индустрии в ОО подходах, РМД будет искать варианты замены процедурных расширений на какую-то декларативную хрень.
Я детально пояснял про то, что подходы, основанные на ООП, просто не имеют к БД никакого отношения. Разумеется, разочарование))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292319
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoЛюбой может убедиться,
Что РМД - ошибка природы? Разумеется. Это я честно копирую Ваш стиль обсуждения вопросов по существу, вероятно, общепринятый на sql.ru. Видите, стараюсь, учусь))
Мы же уже договорились, что я - идиот и впариваю ахинею)) Вот, пытаюсь понять Ваше мнение о системе U-gene.
vadiminfoОно и видно. "Знание" так и прет.
Вроде U-gene про БЗ не говорил. Из какой части системы оно прет?
vadiminfoНу, разве, для тех для кого между уровнями разницы нет. "Должна быть" одна и таже модель повидмому, потому уровни ничем не "должны" отличаьтся. Иначе как бы и модели могут отличаться, скорее всего.
То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.
vadiminfoДа уж спасибо, что не как ЧАЛа научили.
Вернитесь к теме. наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292351
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
БредятинаНаивно)) Мягко говоря. Поработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой создания и эксплуатации БД, в том числе, именно потому что легкость "подгонки алгоритмов" превосходит "реляционные системы" настолько, что даже сравнивать не имеет смысла.

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

БредятинаЯ детально пояснял про то, что подходы, основанные на ООП, просто не имеют к БД никакого отношения. Разумеется, разочарование))
не имеют. а кто-то с этим спорит ?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292395
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаЧто РМД - ошибка природы?
Это Вашу мечту Вы пытались подбросить вместо единственной удачной Вашей мыстли:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))



БредятинаТо, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.


Очевидно, что это попытка сомнителный недосток (возможно, это и не недостаток вообще) превратить в неприемлемый. И впарить ахинею типа РБД якобы плохая БД. Типа "знания" которые так и прут.


БредятинаУ него - разные модели что ли???)))
У большинчства пока разные: ER и РМД..
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292486
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!вериться с трудом, ваши рассуждения выдают в вас то, что вы не сталкивались с системами где через год данные выросли по экспоненте и алгоритмы, что были наиболее оптимальны на этих же данных год назад совершенно не годятся.
Мне остается только адекватно отвечать - я уверен, что Вы никогда не сталкивались.
Yo.!не имеют. а кто-то с этим спорит ?
Отлично. У U-gene классы не из ООП?
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292503
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoЭто Вашу мечту Вы пытались подбросить вместо единственной удачной Вашей мыстли
Рад, что поняли, наконец-то, что РМД - ошибка природы))
vadiminfoОчевидно, что это попытка сомнителный недосток (возможно, это и не недостаток вообще) превратить в неприемлемый. И впарить ахинею типа РБД якобы плохая БД. Типа "знания" которые так и прут.
То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.
У U-gene не БЗ. Откуда прут знания?
vadiminfoУ большинчства пока разные: ER и РМД..
Это мы уже тщательно разобрали:
13577413
Вернитесь к теме, наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292562
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаТо, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.

Самоучек?
Ить до этого считалось, что на логическом должна быть лучшая для логического.
И в общем случае, для разных проектов это могут быть разные типы МД в общем случае. И на момент концептуального проектирования, может быть, не известно какая именно подойдет для логического.


Я уже не говорю про то, что "очевидное для всех" предполагает, что эта одна будет лучшей среди всех уконцептуальных при концептуальном проектировании, и среди логических при логическом. И с какого перепугу это может быть очевидно?
Такая теорема не известна, а вот обратные про комбайны, как бы слышали.



БредятинаvadiminfoУ большинчства пока разные: ER и РМД..
Это мы уже тщательно разобрали:

И что они меньше стали использоваться после Ваших разборок? Тем более что:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292862
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бредятина PSV100: здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы

ORM (где под О понимается семантический аспект, в первую очередь) - объективная необходимость. Так как прямое использование РМД невозможно. Это не значит, вероятно, что РМД - ошибка природы. Собственно, U-gene и доказывает, что РМД - не ошибка, обходясь, как он уверяет, без ORM.

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

Вы напрасно добавили физический уровень. Ведь речь шла только о проектировании (на основе МД в первом смысле, по дейту) и использовании МД во втором смысле, по Дейту (независимо от физической реализации данных). При использовании "реляционных систем" архитектура "модель верхнего уровня+маппинг+РМД" неизбежна. Если только не заменить РМД на модель EAV или использовать разработку U-gene))

vadiminfo: Еще бы.

Что РМД - ошибка природы? Быстро согласились, на этот раз))

vadiminfo: Если эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха),

Факт, что это не так. На логическом уровне РМД уступает по всем аспектам. А эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))

[...]

Бесполезная реализация.
14026636
За 30 лет нашел лишь одно ясное применение алгебре, когда она органично сочетается с семантикой.

[...]

Заблуждение. Практически, ни одной задачи)) Поэтому и приходится применять архитектуру "модель+маппинг+РМД", часто даже не РМД, а EAV.

[...]

Рад, что поняли, наконец-то, что РМД - ошибка природы))

[...]

и т.д.

U-gene: Кстати, всегда думал, что ... разница между программистами и спецами по БД высосана из пальца. Оказывается, я ошибался.

Это точно. Между ними непреодолимая пропасть))


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

ВикипедияORM (англ. Object-relational mapping, рус. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как проприетарные, так и свободные реализации этой технологии.

[...]

Решение проблемы хранения данных существует — это реляционные системы управления базами данных. Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к семантическому провалу, заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.

[...]

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

[...]

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

Некоторые пакеты решают эту проблему, предоставляя библиотеки классов, способных выполнять такие преобразования автоматически. Имея список таблиц в базе данных и объектов в программе, они автоматически преобразуют запросы из одного вида в другой. В результате запроса объекта «человек» (из примера с адресной книгой) необходимый SQL-запрос будет сформирован и выполнен, а результаты «волшебным» образом преобразованы в объекты «номер телефона» внутри программы.

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

На практике всё не так просто и очевидно. Все системы ORM обычно проявляют себя в том или ином виде, уменьшая в некотором роде возможность игнорирования базы данных. Более того, слой транзакций может быть медленным и неэффективным (особенно в терминах сгенерированного SQL). Все это может привести к тому, что программы будут работать медленнее и использовать больше памяти, чем программы, написанные «вручную».

Но ORM избавляет программиста от написания большого количества кода, часто однообразного и подверженного ошибкам, тем самым значительно повышая скорость разработки. Кроме того, большинство современных реализаций ORM позволяют программисту при необходимости самому жёстко задать код SQL-запросов, который будет использоваться при тех или иных действиях (сохранение в базу данных, загрузка, поиск и т. д.) с постоянным объектом.
[...]


Но я одного не понимаю, если есть какая-то потребность в клиентском коде манипулировать какими-то объектами, то почему обязательно или неизбежно применять для этого "виртуальную объектную базу данных", неизбежно создавая при этом проблемы самому себе? (к тому же, чем плоха EAV, когда структура объектов не известна на этапе проектирования и она создаётся/изменяется в процессе эксплуатации согласно целям системы?).

Я допустил ошибку здесь , когда назвал тот код корявым словом "какой-то ORM". Я вынужден убрать его оттуда, и назвать вещи своими именами - "embedded SQL", как этим обзываются производители SQL-СУБД.

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

P.S. И таки да, ORM - это ошибка природы (прежде всего, в адрес типовых ынтырпрайз-ORM).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292873
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoСамоучек?
Для всех, кто понимает БД.
vadiminfoИть до этого считалось, что на логическом должна быть лучшая для логического. И в общем случае, для разных проектов это могут быть разные типы МД в общем случае. И на момент концептуального проектирования, может быть, не известно какая именно подойдет для логического.
До того, как поняли, было много разных заблуждений.
vadiminfoЯ уже не говорю про то, что "очевидное для всех" предполагает, что эта одна будет лучшей среди всех уконцептуальных при концептуальном проектировании, и среди логических при логическом. И с какого перепугу это может быть очевидно?
Такая теорема не известна, а вот обратные про комбайны, как бы слышали.
Это мы уже тщательно разобрали:
13577413
Вернитесь к теме, наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
vadiminfoИ что они меньше стали использоваться после Ваших разборок?
РМД - это они?)) Нет, не меньше. Их по-прежнему, вынуждены использовать на нижнем уровне в архитектуре "МД+маппинг+МД" из-за проблем с образованием.
vadiminfoТем более что:БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))
А что же Вы так наивно ведетесь, и реагируете на идиота и его ахинею. Что Вам так мешает помолчать?)) Тем более, что никак не хотите говорить по существу. И спросить U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292916
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Поскольку я программист, и естественно, скудоумный в области теорий идеальных БД,
Я здесь ничего не говорю о каких-то "теориях идеальных БД". Ни в коем случае. Вопрос про две модели абсолютно практический.
PSV100то вынужден обратиться в википедию , чтобы наконец-то выяснить, что же такое "маппинг":
ВикипедияORM (англ. Object-relational mapping, рус. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».
Заблуждение программиста, написавшего этот текст. И далекого от баз данных. Задайте себе вопрос: а база метаданных (объектная) тоже виртуальная??)) Вот постепенно разбираемся как, все-таки, U-gene моделирует данные. См. П1 и П2.
PSV100Но я одного не понимаю, если есть какая-то потребность в клиентском коде манипулировать какими-то объектами, то почему обязательно или неизбежно применять для этого "виртуальную объектную базу данных", неизбежно создавая при этом проблемы самому себе? (к тому же, чем плоха EAV, когда структура объектов не известна на этапе проектирования и она создаётся/изменяется в процессе эксплуатации согласно целям системы?).
Существенная неточность. EAV на (логическом) уровне хранения данных. Вместо РМД. Но в "реляционной системе" (в смысле физического уровня).
PSV100Кстати, одна из самых практичных технологий, дающая возможность разрабатывать клиентский код как-будто внутри SQL-сервера, естественным образом не создавая никаких "концептуальных недоразумений" в мозгах, вне зависимости от того, применяются ли объекты или атомарные типы данных.
Вот как все замечательно разрешилось)))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38292956
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-geneЕсли я что то понимаю, накладная и акт - два разных документа (один может быть основанием для второго). Соответственно, и в системе они должны быть разными объектами.

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

U-geneНет, так ракеты не летают.

И я о том же. Если ни о чём не думать, то ракеты так не летают. А если подумать, то такие ракеты вообще не летают.


Вы ранее писали о том, что не рассматриваете вопросы концептуального проектирования. И я подозреваю, что у Вас есть какое-то концептуальное недопонимание, что-ли. Вот Ваши цитаты:
U-geneПочитал я ссылку на хабру, почитал топик, аж запечалился.
...
Собственно я и пост этот написал потому, что снова увидел фразы о том, что "с объектной моделью не всё зашибись", что "она не подходит для двузвенки", что "это будет на СУБД, а фреймворк". Я только одно могу сказать по этому поводу - бытие определяет сознание. :)
...
Это я обобщил знакомыми словами мысль Дейкстра "Используемые инструменты оказывают глубокое (и окольное!) влияние на наши способ мышления, и, следовательно, на нашей способности к мышлению".
...
Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. Ситуация для меня обычная, привычная и понятная. Поэтому я сразу даю видео, где показано как эта СУБД работает и объяснены основные принципы как можно объединять ОО и РМ, так, что бы они друг другу не мешали, и даже помогали. Тема запутанная, у людей в голове каша, двумя словами от этой каши не избавишь, а на словесные баталии мы потратим больше времени, чем 36 минут (длительность видео). Я даже не настаиваю: хотите - смотрите, не хотите - не смотрите.
...
Идея как раз в том, что вообще не надо ничего расширять. У меня следующая аналогия. Есть квадрат и есть круг. Требуется найти что то, что было бы и круглым и квадратным. Все пытаются как то "расширить" одну фигуру до другой и изобразить то закругленный квадрат, то оквадраченный круг (...не знаю, что это такое, сами попробуйте представить). Моя система в этой аналогии - цилиндр. Одна проекция - правильный круг, другая (ортогональная) - правильный квадрат, а для того, что бы соотнести проекции используются имена, общие для обеих проекций.
...
4) "рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи" - не окажется,ни рано ни поздно. Какую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины. Потому язык изначально построен так, что бы эффективно транслироваться, вместе с ключами индексами и запросам.
...
Думать надо по-другому.Забудьте про СУБД как про то, что стоит где то сбоку и используется только для хранения данных. Представьте себе компьютер с ассоциативной памятью, который динамически может создавать новые ассоциации. Задача - создать для него ОО транслятор. Создали. А тут дополнительный профит появился - эта ассоциативная память заодно является персистентной, значит объекты персистентные, значит можно использовать эту систему как СУБД.
...
1) Вот из-за таких вопросов я и отказываюсь лезть на концептуальный уровень. Взамен я предлагаю систему, где есть и классы и таблицы, и которую каждый может использовать как хочет. Не нравятся классы - пользуйтесь только таблицами. А кому-то только классы нравятся. Ну а кто-нибудь захочет изобразить комбинированную схему.
2) А! Вы думаете, что в процессе нормализации выявляются какие то сущности. А я думаю, что нормализация, как все остальное, что проходит в рамках реляционной модели, к этим непонятным и неопределенным сущностям (и др. концептуальным вещам) отношения вообще не имеет. Не бывает отдельно строк накладной и заголовка. И, нормализовав данные накладной, можно продолжать думать о ней, как о едином целом. А в RxO вы можете эту мысль реализовать.
3) Опять ORM. Я даже пример 14390674 дал, что бы показать что RxO - это не ORM, что в RxO классы рядом и вместе с таблицами, что это одна система, а не попытка насильно поженить две разные. Вот, теперь человека перепугали.:)
...
Именно эти вещи я имел в виду, когда говорил, что "бытиё определяет сознание". Кстати, всегда думал, что разница между программистами и спецами по БД высосана из пальца. Оказывается, я ошибался.


Ну, меня никто не перепугал... Признаюсь, что Ваши цитаты и задели за живые "IT-раны". Речь не идёт об обзывательств на счёт ORM. Я с Вами согласен, что RxO - это не ORM. К тому же, я вижу, что RxO сам по себе может нуждаться в каком-то ORM. Вы утверждаете, что ликвидируете все проблемы несостыковки между ООП и РМД, публикуете "НадРеляционный Манифест" и т.д. Но не уточняете, в каком именно месте будут ликвидированы проблемы. Если RxO - какой-то "акцесс/фокспро", замкнутая в себе вещь, то вполне можно реализовать гармоничное "ООП-РМД", и то частично. Например, как-то так:

CREATE HTML FORM МоиНакладные ON CLASS Накладные[<такое-то where>].Содержимое[<where...>] (...);

Т.е. натравив форму непосредственно на класс, а не на результат select-выборки.

Но в этом случае некорректно говорить о революции в мире БД. Если RxO - это некий открытый "сервер" для общения, то типовая разработка будет выстроена так:

(Клиент + API-доступа) -> (RxO) -> (SQL) -> (БД)

Т.е. всё так же, как и при работе с типовым SQL-сервером, т.е. отправка RxO-запросов и обработка результатов, опять же в виде тех же табличных данных. Только появляется дополнительный объектный препроцессор/транслятор/интерпретатор, берущий весь основной удар на себя. В рамках "клиента" вполне возможно задействование какого-то ORM, а точнее уже какого-то OOM - Object-to-Object Mapping.

Здесь стоит не забывать, что ненадёжность системы состоит из произведения ненадёжности её компонент.

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

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


Далее, концепции мейнстрим-ООП Вы развили до совершенной формы. Кроме того, что классы выражают тип (устройство данных плюс операции над ними), но и класс сразу же есть и хранимая коллекция объектов. Более того, расширили понятие наследования до наследования и данных (так, что-ли, это назвать). И основная фишка проекта - это так называемые "объектные выражения" (или что-то в этом роде), где через простую и краткую форму вида "Foo.Bar" можно заменить целую SQL-простыню, согласно пониманию наследования.

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

Ну и технические проблемы. Основная фишка проекта становится и его же основным минусом. Рассмотрим всего лишь три класса:

(класс A -> класс B), класс C

где, класс B - потомок от А. Глянем, чего же можно применять внутри вычислимой "реализации" класса B, т.е. где-то в "ALTER B REALIZE ...":

- если мы обратимся к предку А, т.е. "SELECT ... FROM A ...", то сразу получим "зацикливание", т.к. обращение к А ведёт к автоматическому "наследованию" данных, т.е. к выборке из всех потомков, и вновь к срабатыванию действий в "ALTER B REALIZE ...";

- обратится к своим потомкам мы тоже не можем по тем же причинам (тем более мы о них и не знаем);

- если обратится к классу C, то он тоже, в свою очередь, может обратиться к классу А (в своих "REALIZE"), и опять замкнутый круг...

Всё выше сказанное применимо и к "методам". Если разрешить внутри классов полную свободу, то это приведёт к следующему:

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

- вряд ли возможна полная "sql-трансформация", и без интерпретатора не обойтись, и хорошо, если он сможет разруливать зацикливание, а не уйдёт в вечную нирвану.

Т.о. внутри классов ("REALIZE", методы) возможно лишь обращение к свойствам "текущего" объекта, в т.ч. и к данным "табличных" свойств. Иными словами, классы не могут работать друг с другом.

И я не понимаю, зачем Вы планируете ещё ввести и "таблицы". Ведь они для реальной практики автоматом потянут за собой триггеры, поэтому обращаться и к таблицам из классов невозможно. Фактически, таблицы - те же классы, без предков и потомков (к тому же выглядеть это будет так, как будто в java добавить структуры, как таблицы, и независимые функции, как процедуры/триггеры).

Таким образом, классы в RxO представляют собой набор относительно независимых db-классов, часть из которых связаны через наследование, в т.ч. "и данных". Фактически, это а-ля объектная СУБД, но немного продвинутая. Если Вы планируете реализовывать "разработку" внутри RxO, то это крайне ограниченно. Классы пригодны лишь для внешних RxO-запросов для типовых CRUD-операций. И если говорить о "продвинутой СУБД", то Вы обречены на создание новой прикладной оболочки. Ваша миссия будет расширена уже до "НадОбъектного революционного Манифеста" (или "межобъектного", для создания уже "прикладных" классов), и Вы продолжите стирать все грани уже в "межклассовых отношениях".


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

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

Подход, когда аналитики и архитекторы должны непосредственным образом участвовать и в работе команды программистов (сами огребать все проблемы в реализации того, что они наанализировали и напроектировали), пропагандирует, кстати, Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).


P.S.

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

Во-вторых, прошу правильно воспринять мою критику. Она не направлена на типовое "ненужно/закопать", нет. Возможно, она как-то сможет Вам помочь в Вашей дальнейшей разработке.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293055
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
БредятинаPSV100Кстати, одна из самых практичных технологий, дающая возможность разрабатывать клиентский код как-будто внутри SQL-сервера, естественным образом не создавая никаких "концептуальных недоразумений" в мозгах, вне зависимости от того, применяются ли объекты или атомарные типы данных.
Вот как все замечательно разрешилось)))

Когда будет промышленная Neo4j/OrientDB я вынужден буду решать свои задачи по другому чудесному образу.

В целом, я понимаю, что Вы хотите выразить (и во многом с Вами согласен). Но я не понимаю, причём здесь тот же U-gene, которого Вы пытаетесь учить жить (как и всех остальных). Я тоже увидел в решении от U-gene концептуальные недостатки (насколько смог понять из-за своей необразованности), но я не пытаюсь его учить, подтвердив нюансы (в нормальной конструктивной беседе) я их все выложил на полочке, чтобы он смог на них посмотреть (в т.ч. и выяснить, не туплю ли я, на самом деле).

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

P.S. Все проблемы только от Вашего стиля научных диалогов на форумах, не более. В результате все темы форума разрастаются до невероятных размеров, переполнены информационным мусором, бОльшая часть которого сплошной негатив.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293058
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаДля всех, кто понимает БД.


Особенно Вы много понимаете.



БредятинаЭто мы уже тщательно разобрали:


Угу. Особенно нам удалось продвинуться в этом:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293062
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаПоработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой
работал с MUMPS (ДИАМС 3.1 на СМ1420) примерно с 1988 по 1992. В промежутках работал с РСУБД. Не смотря на то, что мне нравилось писать на MUMPS всякие системные штучки, нисколько не жалею, что ушел с нее, и никаких сожалений не испытываю.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293158
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdvБредятинаПоработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой
работал с MUMPS (ДИАМС 3.1 на СМ1420) примерно с 1988 по 1992. В промежутках работал с РСУБД. Не смотря на то, что мне нравилось писать на MUMPS всякие системные штучки, нисколько не жалею, что ушел с нее, и никаких сожалений не испытываю.

И благодарю Вас, что Вы, по крайней мере, не занимаетесь научными исследованиями на уровне детского сада, по мотивам этого :

БредятинаdoublefintАндрей Леонидович, заинтересовали также ваши рассуждения о неполноценности SQL-запросов (вы упоминали статистику запросов). Можно в таком же формате как про связи или ссылку? Спасибо!

1) Большинство запросов в типичных OLTP-приложениях связаны с поиском экземпляра объекта (сущности определенного типа) и экземпляров объекта, связанных с конкретным экземпляром другого объекта (записи документа, договоры клиента и т.п.). Оптимизировать здесь нечего (сердце "реляционной системы" - оптимизатор - бесполезен), а интегрированный язык БД удобнее двух языков (процедурного и декларативного) пусть и с общим заголовком, типа PL/SQL.
2) Большинство оставшихся запросов относятся к классу так называемых непредусмотренных. Они формулируются пользователями с использованием интерактивного интерфейса, и язык, на котором реализованы вычислительные мощности этого интерфейса не имеет никакого значения. Так же, как и в п. 1) интегрированный язык и структуры, используемые в MUMPS, как минимум, не менее эффективны, чем два языка с разными парадигмами и разными структурами. Но, повторю, не имеет никакого значения на каком именно языке реализованы непредусмотренные запросы и отчеты в рамках интерактивного интерфейса.
3) Наконец, остались "сложные вычисления", например, расчет фактической себестоимости продукции или расчет заработной платы. У меня нет сомнений в преимуществе MUMPS, как технологии, перед PL/SQL или TSQL. Однако, здесь важно услышать мнение специалистов Cache, которые одинаково хорошо владеют MUMPS (COS) и SQL.

Перспективы связаны с направлениями такого плана
14020854

[...]

Замечу, что "сложные вычисления" по п. 3) содержат, в основном, не сложные запросы, а множество простых.
Для такого типичного фрагмента, как
"Если значение характеристики ih экземпляра ie объекта io не существует, то выполнить программу PRG и завершить текущую программу"
вот код, написанный любителем в среде СУБД на MUMPS

i $$g(io,ie,ih)="" d ^PRG q

а вот попытка написания аналогичного кода профессионалом на языке реляционной системы хранения и обработки данных (РСХОД)

IF NOT EXISTS (SELECT * FROM x WHERE ...)
THEN
CALL PRG() ;
RETURN;
END IF;

Запрос не дописан, не понятно используются ли в нем переменные или имена, но понятно, что интегрированный язык БД мощнее двух языков.

Как я понимаю, глубокие научные исследования были проведены за бортом этих постов, которые выяснили:

- профессионалы не знают, что обычно параметры/переменные в SQL-операторах задаются в виде ":my_param, @my_var, ?other_var" и т.п. (тут у каждого своё, так уж исторически сложилось);

- профессионалы тупые, предпочитают вместо мощной декларативной силы SQL вести разработку "в лоб", строго императивно-последовательно;

- "сложные вычисления" по п. 3 реализуются через множество простых запросов. Иными словами, через миллионы простых запросов (видимо, через "маппинг");

- были пристально изучены все оптимизаторы всех распространённых РСУБД (не забыв даже про sqlite), в типичных OLTP-приложениях они признаны бесполезными (наверное, и даже подсистемы кэширования данных);

- ну и т.д.

Причём, подозреваю, что научные исследования также эффективно задействовали методики из прошлого века, на заре IT, когда скрупулезно считали количество вводимых оператором символов на терминале. И научные исследования игнорируют современные текстовые редакторы, где через интерактивные "сниппеты" можно набирать sql-текст, введя несколько букв (и даже с меньшими затратами, так как не нужно одновременно нажимать shift для ввода символов вида "$, ^" и т.п.) Я уже не говорю о том, как обучить "индуса" такому: i $$g(io,ie,ih)="" d ^PRG q
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293169
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Код клиента выше вполне себе ORM, т.е. формируем коллекцию именно объектов на основе реляционной таблицы в БД.Ещё раз повторю: представление, что объекты отображаются на таблицы - концептуальная ошибка.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293178
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаУточните: данные хранятся в реляционной БД в каком виде? В реляционном?

Уточняю. Данные хранятся в РБД (= "память ассоциативной машины") в виде хранимых отношений. Если это значит "в релционном", то да, "в реляционном".

БредятинаАтрибуты отношений - это свойства "неизвестно чего" (так как Вы запрещаете использовать, например, такие термины как "сущность" или связь")? Или еще и термин "свойство" мы тоже не можем использовать?

Атрибуты отношений - это атрибуты отношений. В этой древней 770826 , но по прежнему актуальной теме, я озвучиваю свой взгляд. В РМД вообще нет никакой семантики, нет сущностей, связей, свойств. Для меня это чистой воды формализм и математика. Вот еще пример обсуждения 3589798 , где пытаюсь донести, что не стоит воспринимать РМД и связаные с ней формальные понятия, как средство для описания предметной области.

БредятинаSELECT * FROM Студент Дайте другой SELECT, где атрибуты перечислены. Я уже сказал, что "SELECT * " применительно к классам пока не работает (потому что не определено).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293180
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovPSV100Код клиента выше вполне себе ORM, т.е. формируем коллекцию именно объектов на основе реляционной таблицы в БД.Ещё раз повторю: представление, что объекты отображаются на таблицы - концептуальная ошибка.

Я уже всё уточнил (что, однако, никак не запрещает реализовать удобные для себя и под задачи абстракции, в том числе и какое-то отображение, в т.ч. и динамическое, если нужно).
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293187
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneДумать надо по-другому.Забудьте про СУБД как про то, что стоит где то сбоку и используется только для хранения данных. Представьте себе компьютер с ассоциативной памятью, который динамически может создавать новые ассоциации. Задача - создать для него ОО транслятор. Создали.... и вляпались в то, что перестанет быть "мелким пятнышком", как только проект выйдет за рамки прототипа.
Подумайте, в свою очередь, об одной простой вещи - прежде, чем вы начнёте создавать объекты и отображать их "куда-то" надо решить несколько задач:
1. Произвести декомпозицию сущностей. Специально использую термин "сущность", т.к. до термина "объект" ещё далеко;
2. Произвести нормализацию того, что спроектировано на этапе 1;
3. Реализовать набор примитивов (DML-запросы, PL/SQL-процедуры, включая процедуры на "внешнем" языке СУБД). При необходимости, произвести де нормализацию структур СУБД;
4. После того, как "устаканился" набор, интерфейс и семантика примитивов - начать реализацию объектов, работающих с сущностями через примитивы.
Так вот, на этапах с первого по третий объекты, как минимум, не нужны. Для достаточно широкого класса задач - просто вредны.

P.S. "ООП поверх СУБД" (ORM, RxO или что ещё) полезен тогда, когда "примитивы примитивны" (CRUD-задачи) и вся семантика, без особого ущерба, может быть сосредоточена в объектах. Круг таких задач широк, но далеко не всеобъемлющ.

P.P.S. Постоянство это не просто свойство - это свойство, меняющее семантику. А искусственный интеллект всё ещё не создан.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293255
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я не очень Ваши вопросы понимаю. На то, что понял, пытаюсь ответить.

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

Неужели Вы не разрабатывали реальные промышленные системы? Разрабатываю. PSV100Ну да ладно, чёрт с тем, что через одно физическое невозможно отобразить разное логическое. Не понял. Дайте пример. PSV100Пусть те же "накладные" и "акты" разные документы, каждые со своими данными. Но в реальных условиях эксплуатации может возникнуть потребность хранить их в одной физической таблице (так м.б. оптимальней для массовых операций, это м.б. индекс-таблица или кластерная и т.д.). Реализовать такой выкрутас через RxO никак невозможно (об этом ниже).


Ну почему...? Почему невозможно?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CLASS DOCS
{
  No INT;
}

ALTER DOCS REALIZE No AS Stored;

CLASS DerivedDOCS EXTENDS DOCS
{
  SourceDos DOCS; //ссылка на связанный документ
}

ALTER DerivedDOCS REALIZE No AS 
SELECT No FROM SourceDoc;


Теперь данные объектов DOCS хранятся, они же отображаются в объектах DerivedDOC. Или это опять не то?
Кстати, при чем здесь таблицы ? :)
PSV100 Но не уточняете, в каком именно месте будут ликвидированы проблемы.
Специально переслушал, пересмотрел. Звучат фразы "расширение реляционных СУБД" "прототип реализует несколько новых команд" (что КМК подразумевает, что реляционные СУБД и старые команды никуда не деваются). Здесь 14380105 я написал, "Я вижу это как расширение SQL сервера. То есть, все что есть в РСУБД сейчас, сохраняется, появляются несколько новых команд. Все остальное полумеры." То есть, RxO - это не надстройка, а способ расширить SQL используемый в СУБД.
PSV100Если RxO - какой-то "акцесс/фокспро", замкнутая в себе вещь, то вполне можно реализовать гармоничное "ООП-РМД", и то частично.Т.е. натравив форму непосредственно на класс, а не на результат select-выборки.
1) Не понимаю. Какое отношение формы имеют к ООП и к классам?
2) Я стараюсь отделить мух от котлет. Если схема данных доступна, то всяко можно сгенерить интерфейс (вплоть до кнопок, которые бы соответствовали методам), Или Stub-класс в приложении, объекты которого инкапсулировали бы общение с объектами на стороне бд Но это уже следующие шаги.
PSV100Но в этом случае некорректно говорить о революции в мире БД. Если RxO - это некий открытый "сервер" для общения, то типовая разработка будет выстроена так:
(Клиент + API-доступа) -> (RxO) -> (SQL) -> (БД)

Нет не так.
(Клиент + API-доступа) -> (SQL+RxO расширения) -> (БД)
PSV100Т.е. всё так же, как и при работе с типовым SQL-сервером, т.е. отправка RxO-запросов и обработка результатов, опять же в виде тех же табличных данных. Только появляется дополнительный объектный препроцессор/транслятор/интерпретатор, берущий весь основной удар на себя. В рамках "клиента" вполне возможно задействование какого-то ORM, а точнее уже какого-то OOM - Object-to-Object Mapping. Это, как я понимаю и есть stub-классы.
PSV100Здесь стоит не забывать, что ненадёжность системы состоит из произведения ненадёжности её компонент. Да-да. RxO явно проще, чем текущие ОРМы.
PSV100Как я понимаю, под "тлетворным влиянием Запада" Вы довели идеи мейнстрим-ООП, фактически, до абсолюта (не обращая внимание на то, это мейнстрим-ООП не есть продукт передовой технической мысли....
В свое время это была очень передовая мысль. И ее еще есть куда развивать, именно в плане CS.
PSV100...а результат деятельности IT-бизнеса, т.е. торгашей-шоуменов - "всё есть объекты, объекты - это легко"
Возможно мимо Вас прошел этот топик 14379325 . Повторю. Я вообще не фанат абсолютизма, когда начинают все подгонять под одну гребенку (типа "всё - это объекты"). Я лишь говорю, что объекты - полезная штука, которую часто удобно использовать, что бы описывать какую то часть предметной области. Раз удобно - пусть будут. Я и от таблиц не отказываюсь (в прототипе этого нет, мне это очевидным кажется). Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте.
PSV100Во-первых, Вы почему-то решили, что производители РСУБД маятся фигнёй, годами ломая голову над тем, как бы реализовать хранение данных, чтобы ими можно было вертеть в разные стороны, и так и эдак, да как угодно, чтобы была возможность через одни и те же физические данные выражать разные логические сущности. Вы ликвидировали этот "фатальный недостаток". Это Вы решили, что я решил. RxO расширяет возможности. Все что было - остается.
PSV100В результате в RxO имеется только одна объектная модель, описывающая предметную область и физическое устройство данных, всё в одном флаконе. При этом физические данные насмерть гвоздями прибиты к одной логической сущности. Нет Выше я дал пример. Физическое устройство определяется в реализации классов, которая определяется отдельно от логических сущностей этих классов.
PSV100Вы утверждаете, что в БД не может быть "разорванной" накладной, это только единая накладная и точка (я даже не знаю, смотрели Вы на совокупность строк накладных как на оборотную ведомость). Нет. Я в видео даю пример, где на основании хранимых накладных определяется оборотка по товару. Так же легко можно сделать и наоборот (и даже переделать на ходу).
PSV100Одним словом, Вы выкинули за борт основное достоинство РСУБД. Да тут они все, приглядитесь :)
PSV100И основная фишка проекта - это так называемые "объектные выражения" (или что-то в этом роде), где через простую и краткую форму вида "Foo.Bar" можно заменить целую SQL-простыню, согласно пониманию наследования. Там есть много других фишек. Уже писал 14390609 .
PSV100Здесь есть политические проблемы. Всё таки, ООП рассчитано на то, что где-то на верхнем уровне кто-то что-то реализует, замкнуто и универсально. Далее, кто-то на нижних уровнях использует базовый абстрактный функционал, при чём его уже не должно волновать, как он устроен внутри. И, например, кто-то сверху реализовал выборку реестра накладных, формально закладываясь на типовую организацию документов, а кто-то где-то ниже реализовал ряд свойств у документа как вычислимые на основе выборки агрегатов из "содержимого" (ибо так тру-ООП). И в результате на ровном месте получили коррелированные подзапросы (или при выборке "шапок" для каждой строки таблицы будут запускать запросы над "строками" и т.д.), т.е. эксплуатирующие будут оптимизировать опять же через "мейнстрим-железо" (ну или вновь здравствуй рефакторинг). Не понимаю. Именно это я демонстрирую в видео. Там сначала создается класс SHIPMENT, откуда я достаю данные запросом, а затем я рядом добавляю класс-наследник SALES, и я (ничего не рефакторя!) вытаскиваю тем же запросом данные в т.ч. уже из класса наследника, где они вычисляются. Или объясните, что Вы имеете в виду.

PSV100Ну и технические проблемы....
Да. Только я не понял Ваших резонов вообще.
1) О каком зацикливании Вы говорите? То, что Вы говорите (если я правильно это понял) выглядит как "если мы из функции вызовем эту же функцию, то получится бесконечная рекурсия". Да. Это св-во любого языка, допускающего рекурсивные вызовы. И что? Зациклить можно все, что угодно. Это КМК от прокладки зависит. Приведите пример поконкретнее, я не совсем уверен, что Вы его отчетливо видите.
2) То же самое - про "мусор в реализациях".
3) Что такое "полная компиляция"? Почему ее "невозможно осуществить"?
4) Что такое - "SQL трансформация"? Почему она "невозможна полностью"?
5 Что такое"абстрактные связи"? Почему их "нельзя разрулить до конца"?

PSV100Т.о. внутри классов ("REALIZE", методы) возможно лишь обращение к свойствам "текущего" объекта, в т.ч. и к данным "табличных" свойств. Иными словами, классы не могут работать друг с другом.Ну вот сначала ответьте на все вопросы... потом будете делать этот печальные выводы.

PSV100И я не понимаю, зачем Вы планируете ещё ввести и "таблицы". Ведь они для реальной практики автоматом потянут за собой триггеры, поэтому обращаться и к таблицам из классов невозможно. Фактически, таблицы - те же классы, без предков и потомков (к тому же выглядеть это будет так, как будто в java добавить структуры, как таблицы, и независимые функции, как процедуры/триггеры). Все наоборот. Я к таблицам классы добавляю. RxO - это расширение, точно так же как CLASS в С++ дополнил STRUCT, существовавшие в plain С. Обращаться можно, без проблем. Кстати, таблицы - это не классы (это первая большая ошибка по Дейту).

PSV100Таким образом, классы в RxO представляют собой набор относительно независимых db-классов, часть из которых связаны через наследование, в т.ч. "и данных". Фактически, это а-ля объектная СУБД, но немного продвинутая. Если Вы планируете реализовывать "разработку" внутри RxO, то это крайне ограниченно. Классы пригодны лишь для внешних RxO-запросов для типовых CRUD-операций. И если говорить о "продвинутой СУБД", то Вы обречены на создание новой прикладной оболочки. Ваша миссия будет расширена уже до "НадОбъектного революционного Манифеста" (или "межобъектного", для создания уже "прикладных" классов), и Вы продолжите стирать все грани уже в "межклассовых отношениях". Что такое - "относительно независимые классы"? Дальше у меня впечатление, что Вы сами с собой о чем-то своем говорите.

PSV100Я напомню цитату, которую я привёл, как только увидел Вашу презентацию:...Я напомню про миллионы программистов, которые забыли или вообще не знают про asm, успешно заизолированный двумя уровнями ниже.

Так что, вопросов на Ваши вопросы больше чем их самих. Надеюсь на ответы.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293262
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov... и вляпались в то, что перестанет быть "мелким пятнышком", как только проект выйдет за рамки прототипа. Неа не вляпались. Просто создали транслятор.
Basil A. SidorovПодумайте, в свою очередь, об одной простой вещи - прежде, чем вы начнёте создавать объекты и отображать их "куда-то" надо решить несколько задач:
1. Произвести декомпозицию сущностей. Специально использую термин "сущность", т.к. до термина "объект" ещё далеко;
2. Произвести нормализацию того, что спроектировано на этапе 1;
3. Реализовать набор примитивов (DML-запросы, PL/SQL-процедуры, включая процедуры на "внешнем" языке СУБД). При необходимости, произвести де нормализацию структур СУБД;
4. После того, как "устаканился" набор, интерфейс и семантика примитивов - начать реализацию объектов, работающих с сущностями через примитивы.
Так вот, на этапах с первого по третий объекты, как минимум, не нужны.
Может ды, может нет. Я, вообще, про концептуальное проектирование стараюсь не говорить, а все остальное справедливо и для "внутри объектов". В т.ч. нормализация и денормализация, методы и тп.
Basil A. SidorovДля достаточно широкого класса задач - просто вредны. Ну это слова. Во всяком случае сейчас их вообще нет - в предложенном виде.

Basil A. SidorovP.S. "ООП поверх СУБД" (ORM, RxO или что ещё) полезен тогда, когда "примитивы примитивны" (CRUD-задачи) и вся семантика, без особого ущерба, может быть сосредоточена в объектах. Круг таких задач широк... Вот и я про это :)

Basil A. SidorovP.P.S. Постоянство это не просто свойство - это свойство, меняющее семантику. А искусственный интеллект всё ещё не создан. Очень умная фраза. Теперь остается выяснить, как же оно меняет семантику и при чем здесь исскуственный интеллект. :)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293274
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100В целом, я понимаю, что Вы хотите выразить (и во многом с Вами согласен).Говорите конкретнее: с чем согласны. И объясните с чем конкретно, и почему - не согласны.
PSV100Но я не понимаю, причём здесь тот же U-gene, которого Вы пытаетесь учить жить (как и всех остальных).
Как же можно быть согласным или не согласным, не понимая?????
PSV100Я тоже увидел в решении от U-gene концептуальные недостатки (насколько смог понять из-за своей необразованности), но я не пытаюсь его учить, подтвердив нюансы (в нормальной конструктивной беседе) я их все выложил на полочке, чтобы он смог на них посмотреть (в т.ч. и выяснить, не туплю ли я, на самом деле).
А я никаких недостатков не увидел, пока. Так что зря Вы, обнаружив недостатки пытаетесь здесь всех учить, да еще злиться по этому поводу)))
PSV100Я был бы рад, если бы Вы поступили также. Все "идеологические вопросы" решились бы в паре постов, если конкретно толерантно поставить вопросы. U-gene уже давно бы рассказал о "внутренней кухне". Далее Вы бы могли ему указать, мол выброси нафиг РМД и SQL-сервер. Вот есть такие-то "М-модели" (кстати, действительно, не хватает взаимопонимания в правильной терминологии - это "концептуальная модель", "модель данных" и т.п.). Вот такие-то варианты Мхх удобны для такого-то случая, или идеален такой-то Мхх. Далее, этот вариант удобно таким-то образом состыковывать с "пользовательскими моделями" ("хочу такую-то накладную", а также через "Мир состоит так-то ..." вполне успешно выражаются даже вот такие математические сущности).
Нет, так же - говорить банальности, не пытаясь ни в чем разобраться - я не поступлю, конечно.
PSV100Поделились бы своим практическим опытом, мол вот есть варианты MUMPS - одна из самых практичных технических платформ. Те же "М" в них реализуются по таким то принципам ... При чём, есть огромный потенциал для реализации распределенных БД (по кластерам), также физическая модель данных прекрасно позволяет реализовать СУБД в оперативной памяти, имеется резерв для таких-то политик организации сброса надёжных и быстрых дампов на диск, при это нет никаких перестроений уже записанных предыдущих дампов, последующие выборки с дисков просто моментальны и т.д.
Все это знает любой специалист в области БД. Почему я должен говорить о том, что всем понятно?
PSV100P.S. Все проблемы только от Вашего стиля научных диалогов на форумах, не более. В результате все темы форума разрастаются до невероятных размеров, переполнены информационным мусором, бОльшая часть которого сплошной негатив.
Просто банальная неправда. Вам должно быть стыдно. Надеюсь. Негатив идет исключительно от моих оппонентов... Имейте совесть. По существу, как видите, Вы предпочли ничего не отвечать.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293277
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoОсобенно Вы много понимаете.
Конечно.
Вот Вы же ничего по существу не можете сказать))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293280
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvработал с MUMPS (ДИАМС 3.1 на СМ1420) примерно с 1988 по 1992. В промежутках работал с РСУБД. Не смотря на то, что мне нравилось писать на MUMPS всякие системные штучки, нисколько не жалею, что ушел с нее, и никаких сожалений не испытываю.
Говорите ПО СУЩЕСТВУ. И если цитируете, то цитируйте полностью.
И не испытывайте. При чем здесь Ваши ощущения? Вы же, вероятно, не поняли в чем суть MUMPS, если писали всякие системные штучки))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293292
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100И благодарю Вас, что Вы, по крайней мере, не занимаетесь научными исследованиями на уровне детского сада, по мотивам этого...
Вот Вы уже и профессионал, а совсем недавно были о себе невысокого мнения)))
Разумеется такой идиот, как я, может рассуждать только на уровне детского сада)))
PSV100Как я понимаю, глубокие научные исследования были проведены за бортом этих постов, которые выяснили:
- профессионалы не знают, что обычно параметры/переменные в SQL-операторах задаются в виде ":my_param, @my_var, ?other_var" и т.п. (тут у каждого своё, так уж исторически сложилось);
Нет, не верно. Не это выяснили. Вернитесь к обсуждению темы. И поймите про моделирование в системе U-gene.
PSV100- профессионалы тупые, предпочитают вместо мощной декларативной силы SQL вести разработку "в лоб", строго императивно-последовательно;
Нет. Опять не верно.
PSV100- "сложные вычисления" по п. 3 реализуются через множество простых запросов. Иными словами, через миллионы простых запросов (видимо, через "маппинг");
И снова ошибаетесь. Так как не знакомы с технологиями БД, вероятно (не умышленно же))).
PSV100- были пристально изучены все оптимизаторы всех распространённых РСУБД (не забыв даже про sqlite), в типичных OLTP-приложениях они признаны бесполезными (наверное, и даже подсистемы кэширования данных);
А здесь, мне кажется, совершенно искреннее непонимание сути вопроса.
PSV100- ну и т.д.
Да, вроде, итак уже хватает материала, чтобы разбираться с технологиями БД))
PSV100Причём, подозреваю, что научные исследования также эффективно задействовали методики из прошлого века, на заре IT, когда скрупулезно считали количество вводимых оператором символов на терминале. И научные исследования игнорируют современные текстовые редакторы, где через интерактивные "сниппеты" можно набирать sql-текст, введя несколько букв (и даже с меньшими затратами, так как не нужно одновременно нажимать shift для ввода символов вида "$, ^" и т.п.) Я уже не говорю о том, как обучить "индуса" такому: i $$g(io,ie,ih)="" d ^PRG q
Как Вас задело, что на SQL программировать гораздо сложнее))) Да, такому Вас не обучить)))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293308
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneУточняю. Данные хранятся в РБД (= "память ассоциативной машины") в виде хранимых отношений. Если это значит "в релционном", то да, "в реляционном".
Спасибо. Но это не проясняет суть. Если вместо РМД в РСХОД используется модель EAV, то данные все равно ведь хранятся в РБД в виде хранимых отношений)) Так? Уточните, пожалуйста, на простом П1.
U-geneАтрибуты отношений - это атрибуты отношений. В этой древней 770826 , но по прежнему актуальной теме, я озвучиваю свой взгляд. В РМД вообще нет никакой семантики, нет сущностей, связей, свойств. Для меня это чистой воды формализм и математика. Вот еще пример обсуждения 3589798 , где пытаюсь донести, что не стоит воспринимать РМД и связаные с ней формальные понятия, как средство для описания предметной области.
Я полностью согласен. Поэтому РМД и не применима сама по себе. Пожалуйста, поясните что является (или может являться в перспективе, и как тогда будет интегрировано) средством моделирования в Вашей системе. И если такого средства пока нет, то как же Вы моделируете? Без какой-либо модели.
U-geneДайте другой SELECT, где атрибуты перечислены. Я уже сказал, что "SELECT * " применительно к классам пока не работает (потому что не определено).
Атрибуты отношений???)))
Это будет сложнее для меня, пока.
Итак, мы рассматриваем простые примеры. Причем, вместо очевидной (пока) для системы U-gene гипотезы "Мир состоит (только) из сущностей, обладающих свойствами", и понятия Тип сущности, мы договорились (пока) не рассматривать никакие гипотезы об окружающем мире (и моделируемых предметных областях, в частности), и заменили Тип сущности на Класс:

П1
Классы:
Студент {Фамилия, Имя, (Изучает, Предмет)}
Предмет {Наименование}

П2
Классы:
Документ {Дата, Организация-получатель, (Имеет, Отгрузка {(Относится к, Товар), Количество, Сумма}}
Товар {Наименование}

Но, Классы существуют только при описании предметной области (и, извините, на уровне хранения данных). Любой запрос возвращает отношение РМД, но не класс. Например, запрос, эквивалентный
SELECT Фамилия,Имя,Изучает(Предмет) FROM Студент
вернет (считаем, что системные идентификаторы всегда есть в результате запроса):

1 Иванов Петр 1 Алгебра
1 Иванов Петр 7 География
2 Петров Иван 1 Алгебра
2 Петров Иван 3 Химия

Так?
Почему я опять написал Изучает, теперь в запросе? А вот почему. Расширим пример:
П1-1
Классы:
Студент {Фамилия, Имя, (Изучает, Предмет), (Хотел бы изучать, Предмет)}
Предмет {Наименование}

Теперь запрос, эквивалентный
SELECT Фамилия,Имя,Изучает(Предмет),Хотел_бы_изучать(Предмет) FROM Студент
вернет:

1 Иванов Петр 1 Алгебра 3 Химия
1 Иванов Петр 7 География - -
2 Петров Иван 1 Алгебра 7 География
2 Петров Иван 3 Химия - -

Проясните, пожалуйста.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38293880
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаВот Вы же ничего по существу не можете сказать))
Зачем Вам что-то по существу, если до Вас ниче доходит?

Ну разве:

БредятинаРазумеется такой идиот, как я, может рассуждать только на уровне детского сада)))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294324
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneОчень умная фраза. Теперь остается выяснить, как же оно меняет семантику и при чем здесь исскуственный интеллект. :)Если вспомнить классику ООП, то объект - нечто, умеющее принимать и посылать (возможно) типизированные сообщения. И есть три принципа - инкапсуляция, наследование и полиморфизм. Первое - закрывает доступ к реализации объекта, второе - определяет связи между объектами в виде ориентированного графа, третье задаёт "принцип замены" - потомок может использоваться везде, где может использоваться предок.
Разумеется, соображения практической полезности и эффективности реализации влияют на многое: инкапсуляция - не особо жёсткая, в графе наследований могут быть (сложные) циклы, ну и с заменой - тоже не всё гладко.
Так вот в модели ООП нет массы вещей, которые есть и необходимы для эффективной реализации реляционного хранилища. Необходимы настолько, что вы не можете отказаться ни от первичных ключей, ни от ссылочных ограничений, ни от многих других вещей. Вещей, о которых можно просто не думать, если выбрать другой способ реализации постоянства.
Вы уже планируете добавать в RxO различные "реляционные расширения", а в результате получите тот самый гибрид с корнями капусты и листьями редьки.
И окажется, скорее всего, что те задачи, которые эффективно решает RxO, не менее эффективно могут быть решены чем-то вроде комбинации SQL Developer/JDeveloper. Только в этой связке и проблемы со стороны СУБД и проблемы со стороны прикладного кода могут быть решены с максимально возможной эффективностью, а в случае RxO придётся решать задачу преодоления ограничений инструмента.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294445
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovТак вот в модели ООП нет массы вещей, которые есть и необходимы для эффективной реализации реляционного хранилища. Необходимы настолько, что вы не можете отказаться ни от первичных ключей, ни от ссылочных ограничений, ни от многих других вещей. Вещей, о которых можно просто не думать, если выбрать другой способ реализации постоянства. Что и требовалось доказать. В презентация определяются ключи (в т.ч. внешние) между классами, и, далее, говорится о том, что ничто не мешает определять внешние ключи между классами и таблицами. Вы просто не не в курсе темы, на которую пытаетесь разговаривать.

Basil A. SidorovВы уже планируете добавать в RxO различные "реляционные расширения", а в результате получите тот самый гибрид с корнями капусты и листьями редьки.Вы перескакиваете стемы на тему на тему и обратно. Кажется, что какой то момент Вы уже просекли.... ан нет. Я уже говорил, что реляционное память является нативной средой для моих объектов. Я не пытаюсь " сейчас добавить таблицы к моим классам".Я сделал классы, что бы управлять таблицами и сохранил возможность управлять ими напрямую. Для меня последнее настолько очевидно, что я это не реализовал в прототипе. Прототип реализует несколько новых команд. Его цель - показать новые возможности. Старые, очевидные возможности, старые команды в нем отсутствуют.

Basil A. SidorovИ окажется, скорее всего, что те задачи, которые эффективно решает RxO, не менее эффективно могут быть решены чем-то вроде комбинации SQL Developer/JDeveloper. Только в этой связке и проблемы со стороны СУБД и проблемы со стороны прикладного кода могут быть решены с максимально возможной эффективностью, а в случае RxO придётся решать задачу преодоления ограничений инструмента. Я выделил среди всего этого, фразу "скорее всего". То есть всё это - лишь бездоказательные домыслы. Для того, что бы что то доказать, Вам придется изучить. Для этого Вам придется отказаться от нескольких стереотипов (например, противопоставление "прикладной код vs. СУБД"). А отказавшись, Вы увидите, насколько ни о чем, то , что Вы здесь написали.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294486
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаСпасибо. Но это не проясняет суть. Если вместо РМД в РСХОД используется модель EAV, то данные все равно ведь хранятся в РБД в виде хранимых отношений)) Так? Уточните, пожалуйста, на простом П1. Уже уточнял на чем то другом - 14408866 . Можно еще здесь почитать о деталях.
БредятинаПоэтому РМД и не применима сама по себе. Да тьфу ты ) Вот же заладил! Применима она. Только применять ее нужно как модель данных (значений), а не модель предметной области (значений с семантической нагрузкой).


БредятинаПочему я опять написал Изучает, теперь в запросе? Зачем этот вопрос ? В RxO запросе по-другому вообще не написать! Нужно обязательно употребить полный путь, иначе системе не поймет. Если Вы Вы пять раз презентацию смотрели, почему же для Вас это для Вас вдруг стало личным откровением?

В прототипе этот запрос выглядил бы как

Код: plaintext
1.
SELECT #t.Фамилия,#t.Имя, #t.Изучает.Предмет FROM Студент #t
(#t - алиас)

БредятинаРасширим пример:
П1-1
Классы:
Студент {Фамилия, Имя, (Изучает, Предмет), (Хотел бы изучать, Предмет)}
Предмет {Наименование}

Теперь запрос, эквивалентный

SELECT Фамилия,Имя,Изучает(Предмет),Хотел_бы_изучать(Предмет) FROM Студент
вернет:

1 Иванов Петр 1 Алгебра 3 Химия
1 Иванов Петр 7 География - -
2 Петров Иван 1 Алгебра 7 География
2 Петров Иван 3 Химия - -


Нет. Внутри студентов он будет выполнять декартово произведение.

1 Иванов Петр 1 Алгебра 3 Химия
1 Иванов Петр 7 География 3 Химия
2 Петров Иван 1 Алгебра 7 География
2 Петров Иван 3 Химия 7 География

И это... Коллега! Ну тщательнее же в деталях. Это ж объектные идентификаторы. Если у Иванова 1 , то у Алгебры что- то другое.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294570
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneА отказавшись, Вы увидите, насколько ни о чем, то , что Вы здесь написали.Мы эксплуатируем приложение, где уже было два инцидента связанные со вполне безобидной, вроде бы, вещью - созданием (в базе) сессий и отслеживанием их активности.
Так вот, разбираясь с другой проблемой, я наткнулся, на кусок кода, отвечающий за это самое создание сессий. Вполне правильный:
1. Берём соединение из пула;
2. Препарируем запрос;
3. Исполняем параметризованный запрос;
4. Возвращаем соединение в пул.
Каждый этап в отдельности - совершно правилен, логичен и объясним. "Best practics" и всё такое.
Проблема в том, что под реальной нагрузкой в не очень большой системе оно не масштабируется.
Решение, которое делаете вы будет ровно таким же "good enough".
Особенно, когда закончится фан собственно разработки и начнётся мутотень исправления ошибок.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294600
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovU-geneА отказавшись, Вы увидите, насколько ни о чем, то , что Вы здесь написали.Мы эксплуатируем приложение, где уже было два инцидента связанные со вполне безобидной, вроде бы, вещью - созданием (в базе) сессий и отслеживанием их активности.
Так вот, разбираясь с другой проблемой, я наткнулся, на кусок кода, отвечающий за это самое создание сессий. Вполне правильный:
1. Берём соединение из пула;
2. Препарируем запрос;
3. Исполняем параметризованный запрос;
4. Возвращаем соединение в пул.
Каждый этап в отдельности - совершно правилен, логичен и объясним. "Best practics" и всё такое.
Проблема в том, что под реальной нагрузкой в не очень большой системе оно не масштабируется.
Решение, которое делаете вы будет ровно таким же "good enough".
Особенно, когда закончится фан собственно разработки и начнётся мутотень исправления ошибок.Коллега! Какая система? Какие сессии ? Какое приложение ? Я ровно про это и пишу, говоря про стереотип "Приложение vs. СУБД".
Какое "то же самое"? Я только что на ключах показал, что Вы не в курсе, "то же самое" или не "тоже самое". Пишите "скорее всего", как писали.

Что такое "созданием (в базе) сессий"? Дайте кусок кода, пару строк.:)
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294625
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneЧто такое "созданием (в базе) сессий"? Дайте кусок кода, пару строк.:)Вы не разу не видели как и для чего создают-отслеживают сессии?

Тогда минимальная версия без соблюдения синтаксиса:
create table sessions(id primary key, user_id not null, timestamp_opened not null, timestamp_closed)
insert into sessions(сессия, пользователь, сейчас1, null)
update sessions set timestamp_closed = сейчас2 where id = сессия.

А вот дальше начинаются варианты. Под разные цели и задачи.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294675
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-geneЯ не очень Ваши вопросы понимаю. На то, что понял, пытаюсь ответить.
[...]


Спасибо за ответы.

U-geneНет не так.
(Клиент + API-доступа) -> (SQL+RxO расширения) -> (БД)


Одним словом, своим уточнением сути концепции RxO Вы расставили многие вещи по своим местам (имею в виду, в моей голове). Да, в Ваших демо-материалах есть общие изложения на счёт "расширения реляционных СУБД" и т.д., но по прототипу складывалось впечатление, что это некая замкнутая система, или какая-то подсистема внутри (или точнее, над) SQL. Где кроме классов ничего нет. Вы писали о том, что собираетесь скоро добавить "таблицы", о которых тоже складывалось впечатление как об ещё одной абстракции над исходными sql-таблицами. Видимо, косвенно сказывается функционал самого прототипа и имеющийся набор демо-примеров, т.е. что пока есть, то и есть (извините, но пока имеющееся всю суть наглядно не отображает, в общем, дело времени, и это очевидно). И моя беда в том, что я и пытался моделировать именно в этой замкнутой системе, и, естественно, ничего толком так и не смог сделать ("виртуально" удовлетворить своих тараканов).
В т.ч. Вы показали, что готовите (потенциально) полный стек технологии, включая функционал и для "клиентов". Ведь результат RxO-запроса - те же табличные данные, которые нужно как-то обрабатывать. Для этого, кому нужен "Object-to-Object Mapping", возможно применение соответствующих stub-классов.
Надеюсь, что наконец-то, всё правильно понял.

Уточню на счёт "логического-физического". Я не буду обращаться в сторону "концептуальных моделей" и "моделей данных", поскольку здесь в теме форума есть момент несогласованного их взаимопонимания сути, поэтому лучше проведу аналогию с типовыми case-средствами. Они имеют схемы данных, через которые могут отражать логические модели и физические, при этом, ER-сущности могут не всегда тождественно отображаться на физическом уровне (на уровне таблиц и т.д.). Конечно, сравнение условное, т.к. RxO-классы есть уже некая сущность более высокого уровня (грубо, та же "шапка" и "строки" накладной соединяются в одно целое). С понимаем концепции, вроде проблем нет, а вот была проблема с "реализацией" классов ("виртуальной"), чтобы можно было организовать любое нужное физическое хранение (из-за "замкнутой" системы).

Отсюда есть нюансы. Для полной гармонии в "реализации" классов не хватает сокрытия операций создания объекта ("оператор NEW") и операций модификации с удалением (что, кстати, в моём случае, отчасти, тоже было важным недостающим звеном, без которого никак, чтобы причесать прикладную модель). Имеющиеся методы в классах есть методы именно объектов, т.е. если посмотреть на пример:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
ALTER DOCS REALIZE DoShip(inDate DATETIME) AS 
BEGIN
IF(Date IS NULL) THEN
  BEGIN
     Date := inDate;
     Comment := "Shipped!";
  END
END


то заметим, что здесь есть обращение к свойствам "текущего" объекта (имхо, так проще назвать). Короче говоря, нужны какие-то "статические" методы (или методы класса) для манипуляции "над объектами" (для осуществления CRUD-операций). Собственно, подозреваю, что нет причин их не реализовать (ну, также нужен явный запрет/разрешение операций а-ля "grant" и т.п., но, очевидно, что обсуждать здесь нечего, однозначно, всё будет на борту).


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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CREATE CLASS Документы
(   
    Номер       STRING,
    Дата        DATETIME,
    Поставщик   INTEGER,
    Количество  NUMERIC,
    Сумма       CURRENCY,
    ...
    Содержимое SET OF
    (
        Товар       INTEGER,
        Количество  NUMERIC,
        Цена        CURRENCY,
        Сумма       CURRENCY,

        ...
    );
);

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



Какой-то разработчик, реализующий обработку "общих" документов, где-то закладывает RxO-запрос для выборки а-ля:

SELECT ... FROM Документы WHERE ...

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

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

И по каким-то причинам делает "реализацию" класса так, что теперь "Количество", "Сумма" не являются хранимыми, а теперь вычисляются через запрос к "строкам" а-ля:

ALTER Накладные REALIZE (Количество, Сумма, ...) AS select ... sum(.Содержимое.Количество) ... from .Содержимое

Здесь, с учётом того, что сказано в 14408866 (о том, что класс отображается в свою таблицу), я могу предположить, что для "документов" и "накладных" (в т.ч. и для "Содержимого") внутри БД будут созданы соответствующие таблицы. И нужно понимать, как будет теперь транслятор выполнять свою работу при выборке из общих документов:

SELECT ... FROM Документы

Т.е. RxO-запрос м.б. преобразован в SQL вида:

SELECT ... FROM Документы UNION SELECT ... FROM Накладные

где, например, в части выборки из "накладных" через подзапрос будут вычисляться "количество", "сумма" из "содержимого" (т.е. текст sql-запроса будет сформирован на основе RxO-запроса, указанного в "ALTER Накладные REALIZE ..." выше). Или же, например, таблица "накладные" будет создана со столбцами "Количество", "Сумма", для которых будут заданы вычислимые выражения через "computed by". Или же как только где-то в коде будет встречено выражение вида ".Количество", т.е. обращение к соответствующему свойству объекта "накладные", то это вызовет выполнение запроса (или его части, если такое возможно) из "ALTER Накладные REALIZE ...".

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

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


Далее, на счёт "зацикливаний". Возьмём два класса:

класс А
класс B

Это независимые классы, некие базовые заготовки. Появляется новый класс С, потомок от А, где внутри "реализации", т.е. в выражении "ALTER <class> REALIZE ...", имеется RxO-запрос для выборки данных из класса B. Назову подобный запрос через "использует", для краткости в дальнейшем, и буду говорить, что класс С "использует" класс B. В итоге:

класс А -> класс С "использует" B
класс B

Появляется ещё один класс D, потомок от B, который в свою очередь "использует" класс A:

класс А -> класс С "использует" B
класс B -> класс D "использует" A

Разработчики классов С и D могут друг о друге и не знать, соответственно и не подозревать о существовании "соседнего" класса в системе (условно). И, например, при выборке данных из класса А автоматом сработает "realize" в потомке С, что вызовет "обращение" к B, а далее через потомка D вновь "обращаемся" к A.

Конечно, это очевидные вещи, и в том же SQL "зацикливания" вполне возможны. Но, в отличие от "SQL", в рамках RxO имеется дополнительная связь -"наследование", т.е. в дополнение к базовым "объект используется там-то" и "объект использует это" есть и дополнительные связи "предки-потомки", причём которые дают "автоматический вызов" кода (так, что-ли). Учитывая специфику ООП, когда иерархия растёт вертикально и горизонтально (количество потомков на одном уровне), эти связи расширяются довольно не слабо таки. Конечно же, далеко не каждый класс будет содержать опасные места.


Надуманные ли все выше обозначенные проблемы - сомневаюсь, особенно учитывая реальные промышленные проекты с немалым количеством мета-объектов в БД, причём ведь взаимосвязанных. Мне кажется, что подобные проблемы можно как-то контролировать, но в пределах локализованного модуля (а-ля sql-пакета). И вполне, возможно, есть не надуманная потребность ограничить "наследование" в пределах модуля, т.е. не разрешать наследоваться от "внешних" классов. Но это означает и ограничение применения классов (лично я не рискнул бы выпускать "наследование" в опасное бесконтрольное путешествие, и уточню, что это моё личное мнение и только для себя, ничего не кому не навязываю).


И по поводу "полной компиляции". С ней тоже вопросы решились. Но не все. Поскольку уже известно, что RxO гармонично находится внутри SQL-СУБД, то RxO-система должна отвечать и её требованиям. В частности, при выполнении оператора "ALTER <class> REALIZE ..." (и реализация "методов") должны быть установлены все зависимые связи с объектами, т.е. оператор "REALIZE" должен восприниматься как аналог "create or alter/replace procedure ..." в SQL, где для процедуры в метаданных будут прописаны все используемые объекты. Потенциал для этого зависит от принципов работы транслятора, особенно с учётом "наследования", поскольку есть подозрение, что в общем случае, все запросы внутри "реализаций" сразу не попадают в виде SQL непосредственно в СУБД (и она должна устанавливать связи), они "откладываются", и уже во время конкретных операций собирается вся цепочка по иерархии. Повторюсь, это лишь мои подозрения.
Если бы в двух словах концептуально как работает транслятор (на примере тех же "документов выше", т.е. при "наследовании", да плюс вызов метода класса) - стало бы всё ясно с этим вопросом.

*** Уточню, перед тем как публиковать этот пост я заметил, что Вы дали ссылку на документик на счёт "трансляции". Очень быстро посмотрел, пока сплошная "математика", нужно по детальнее посмотреть, возможно разберусь.

Собственно, это основное, что я был обязан выразить более вменяемо. Надеюсь, что получилось.

P.S. На всякий случай, прошу извинить, если мой предыдущий пост имел некую эмоциональную окраску (что, скорее всего, так и есть). В любом случае, это были общие эмоции из-за окружавшей обстановки (на счёт РСУБД, ошибок природы и т.д.), не направлены ни в какую сторону. В свою очередь, я прекрасно понимаю, что приведенные мной Ваши цитаты в том же посте тоже есть продукт такого же эмоционального общения (причём, вынужденного), это очевидно.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38294684
PSV100
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
БредятинаPSV100P.S. Все проблемы только от Вашего стиля научных диалогов на форумах, не более. В результате все темы форума разрастаются до невероятных размеров, переполнены информационным мусором, бОльшая часть которого сплошной негатив.
Просто банальная неправда. Вам должно быть стыдно. Надеюсь. Негатив идет исключительно от моих оппонентов...

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

Я приношу свои извинения.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38295881
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoБредятинаВот Вы же ничего по существу не можете сказать))
Зачем Вам что-то по существу, если до Вас ниче доходит?
Веский аргумент не писать ничего по существу на sql.ru)))
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38295954
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneБредятина...Уточните, пожалуйста, на простом П1. Уже уточнял на чем то другом - 14408866 . Можно еще здесь почитать о деталях.
Это неправда. Надеюсь, не умышленная. Нет ни там, ни там П1.
Пожалуйста, поясните (или подтвердите):

П1
Классы:
Студент {Фамилия, Имя, (Изучает, Предмет)}
Предмет {Наименование}

1) Когда создается класс Студент, будут (на уровне метаданных реляционной системы) созданы три отношения :
Студент { Ид. студента , Фамилия, Имя}
Предмет { Ид. предмета }
Изучение { Ид. изучение , Ид. студента , Ид. предмета }

Примечание 1. Первичные ключи подчеркнуты, а внешние - показаны жирным шрифтом.

2) Класс Предмет, следовательно, не создается (создан автоматически). При попытке его создания будет ошибка. Нужно просто добавить свойства класса. При этом дабавляются атрибуты (если они атомарные - ?) в соответствующее отношение:
Предмет { Ид. предмета , Наименование}
U-geneДа тьфу ты ) Вот же заладил! Применима она. Только применять ее нужно как модель данных (значений), а не модель предметной области (значений с семантической нагрузкой).
Разумеется. Для создания приложений, следовательно, именно не применима. И необходима архитектура "модель верхнего уровня+маппинг+РМД". Или некая технология без маппинга, с которой мы сейчас и разбираемся.
U-geneЗачем этот вопрос ? В RxO запросе по-другому вообще не написать! Нужно обязательно употребить полный путь, иначе системе не поймет. Если Вы Вы пять раз презентацию смотрели, почему же для Вас это для Вас вдруг стало личным откровением?
В прототипе этот запрос выглядил бы как

Код: plaintext
1.
SELECT #t.Фамилия,#t.Имя, #t.Изучает.Предмет FROM Студент #t
(#t - алиас)

Вы прекрасно знаете почему для меня это стало личным откровением)))
U-geneНет. Внутри студентов он будет выполнять декартово произведение.

1 Иванов Петр 1 Алгебра 3 Химия
1 Иванов Петр 7 География 3 Химия
2 Петров Иван 1 Алгебра 7 География
2 Петров Иван 3 Химия 7 География

И это... Коллега! Ну тщательнее же в деталях. Это ж объектные идентификаторы. Если у Иванова 1 , то у Алгебры что- то другое.
Спасибо. Про ид. - сейчас не принципиально. Уникальность в БД или для класса. Принципиально, пока, соответствие классов (пока, неизвестно какой МД) отношениям РМД.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38295976
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PSV100Я не имел в виду конкретно Ваши сообщения на форуме, как и от кого-то иного участника. Речь только об общей негативной атмосфере, которая возникает из-за банальных эмоций (не без почвы, возможно) у участников диалогов, в результате форум заваливается мусором, в котором, действительно, трудно заметить адекватный конструктив. Эмоции распространяются косвенно, что, в частности, меня тоже подтолкнуло к некой вспыльчивости.
Я приношу свои извинения.
Хорошо. Но у меня не возникает эмоций, когда разговор идет по существу.
... Итак в
14416370
Вы обратили внимание только на не существенное последнее предложение.
...
Рейтинг: 0 / 0
Хранение данных с гибкой структурой и запросы к ним
    #38296336
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to U-gene

У меня небольшой вопрос по вашей разработке (не знаю, к сожалению, как ее точнее назвать)
При проектировании баз часто приходится дополнять классические модели еще и EAV расширениями.
Можно ли и каким либо образом обращаться к атрибутам EAV посредством ваших расширений? Какие бонусы это даст (архитектору, разработчику)?
...
Рейтинг: 0 / 0
257 сообщений из 257, показаны все 11 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Хранение данных с гибкой структурой и запросы к ним
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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