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

Откуда:
Сообщений: 157
Бредятина
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).
10 июн 13, 16:16    [14416192]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
Самоучек?

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

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

Это мы уже тщательно разобрали:
13577413
Вернитесь к теме, наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
vadiminfo
И что они меньше стали использоваться после Ваших разборок?

РМД - это они?)) Нет, не меньше. Их по-прежнему, вынуждены использовать на нижнем уровне в архитектуре "МД+маппинг+МД" из-за проблем с образованием.
vadiminfo
Тем более что:
Бредятина
Мы же уже договорились, что я - идиот и впариваю ахинею))

А что же Вы так наивно ведетесь, и реагируете на идиота и его ахинею. Что Вам так мешает помолчать?)) Тем более, что никак не хотите говорить по существу. И спросить U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
10 июн 13, 16:19    [14416218]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
PSV100
Поскольку я программист, и естественно, скудоумный в области теорий идеальных БД,

Я здесь ничего не говорю о каких-то "теориях идеальных БД". Ни в коем случае. Вопрос про две модели абсолютно практический.
PSV100
то вынужден обратиться в википедию, чтобы наконец-то выяснить, что же такое "маппинг":
Википедия
ORM (англ. Object-relational mapping, рус. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».

Заблуждение программиста, написавшего этот текст. И далекого от баз данных. Задайте себе вопрос: а база метаданных (объектная) тоже виртуальная??)) Вот постепенно разбираемся как, все-таки, U-gene моделирует данные. См. П1 и П2.
PSV100
Но я одного не понимаю, если есть какая-то потребность в клиентском коде манипулировать какими-то объектами, то почему обязательно или неизбежно применять для этого "виртуальную объектную базу данных", неизбежно создавая при этом проблемы самому себе? (к тому же, чем плоха EAV, когда структура объектов не известна на этапе проектирования и она создаётся/изменяется в процессе эксплуатации согласно целям системы?).

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

Вот как все замечательно разрешилось)))
10 июн 13, 16:40    [14416370]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
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.

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

Во-вторых, прошу правильно воспринять мою критику. Она не направлена на типовое "ненужно/закопать", нет. Возможно, она как-то сможет Вам помочь в Вашей дальнейшей разработке.
10 июн 13, 16:53    [14416491]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

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

Вот как все замечательно разрешилось)))


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

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

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

P.S. Все проблемы только от Вашего стиля научных диалогов на форумах, не более. В результате все темы форума разрастаются до невероятных размеров, переполнены информационным мусором, бОльшая часть которого сплошной негатив.
10 июн 13, 17:52    [14416897]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Бредятина
Для всех, кто понимает БД.


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



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


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

Бредятина
Мы же уже договорились, что я - идиот и впариваю ахинею))
10 июн 13, 17:56    [14416911]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
Бредятина
Поработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой

работал с MUMPS (ДИАМС 3.1 на СМ1420) примерно с 1988 по 1992. В промежутках работал с РСУБД. Не смотря на то, что мне нравилось писать на MUMPS всякие системные штучки, нисколько не жалею, что ушел с нее, и никаких сожалений не испытываю.
10 июн 13, 17:57    [14416925]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
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
10 июн 13, 19:25    [14417338]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11465
PSV100
Код клиента выше вполне себе ORM, т.е. формируем коллекцию именно объектов на основе реляционной таблицы в БД.
Ещё раз повторю: представление, что объекты отображаются на таблицы - концептуальная ошибка.
10 июн 13, 19:36    [14417368]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина
Уточните: данные хранятся в реляционной БД в каком виде? В реляционном?


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

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


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

Бредятина
SELECT * FROM Студент
Дайте другой SELECT, где атрибуты перечислены. Я уже сказал, что "SELECT * " применительно к классам пока не работает (потому что не определено).
10 июн 13, 19:42    [14417386]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
Basil A. Sidorov
PSV100
Код клиента выше вполне себе ORM, т.е. формируем коллекцию именно объектов на основе реляционной таблицы в БД.
Ещё раз повторю: представление, что объекты отображаются на таблицы - концептуальная ошибка.


Я уже всё уточнил (что, однако, никак не запрещает реализовать удобные для себя и под задачи абстракции, в том числе и какое-то отображение, в т.ч. и динамическое, если нужно).
10 июн 13, 19:44    [14417391]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

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

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

P.P.S. Постоянство это не просто свойство - это свойство, меняющее семантику. А искусственный интеллект всё ещё не создан.
10 июн 13, 19:54    [14417419]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Я не очень Ваши вопросы понимаю. На то, что понял, пытаюсь ответить.

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

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


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

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, успешно заизолированный двумя уровнями ниже.

Так что, вопросов на Ваши вопросы больше чем их самих. Надеюсь на ответы.
10 июн 13, 21:41    [14417663]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

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

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

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

Basil A. Sidorov
P.P.S. Постоянство это не просто свойство - это свойство, меняющее семантику. А искусственный интеллект всё ещё не создан.
Очень умная фраза. Теперь остается выяснить, как же оно меняет семантику и при чем здесь исскуственный интеллект. :)
10 июн 13, 21:55    [14417705]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
PSV100
В целом, я понимаю, что Вы хотите выразить (и во многом с Вами согласен).
Говорите конкретнее: с чем согласны. И объясните с чем конкретно, и почему - не согласны.
PSV100
Но я не понимаю, причём здесь тот же U-gene, которого Вы пытаетесь учить жить (как и всех остальных).

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

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

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

Все это знает любой специалист в области БД. Почему я должен говорить о том, что всем понятно?
PSV100
P.S. Все проблемы только от Вашего стиля научных диалогов на форумах, не более. В результате все темы форума разрастаются до невероятных размеров, переполнены информационным мусором, бОльшая часть которого сплошной негатив.

Просто банальная неправда. Вам должно быть стыдно. Надеюсь. Негатив идет исключительно от моих оппонентов... Имейте совесть. По существу, как видите, Вы предпочли ничего не отвечать.
10 июн 13, 22:18    [14417770]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
Особенно Вы много понимаете.

Конечно.
Вот Вы же ничего по существу не можете сказать))
10 июн 13, 22:19    [14417778]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
kdv
работал с MUMPS (ДИАМС 3.1 на СМ1420) примерно с 1988 по 1992. В промежутках работал с РСУБД. Не смотря на то, что мне нравилось писать на MUMPS всякие системные штучки, нисколько не жалею, что ушел с нее, и никаких сожалений не испытываю.

Говорите ПО СУЩЕСТВУ. И если цитируете, то цитируйте полностью.
И не испытывайте. При чем здесь Ваши ощущения? Вы же, вероятно, не поняли в чем суть MUMPS, если писали всякие системные штучки))
10 июн 13, 22:23    [14417792]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
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 программировать гораздо сложнее))) Да, такому Вас не обучить)))
10 июн 13, 22:35    [14417853]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
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 Химия - -

Проясните, пожалуйста.
10 июн 13, 22:56    [14417936]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Бредятина
Вот Вы же ничего по существу не можете сказать))

Зачем Вам что-то по существу, если до Вас ниче доходит?

Ну разве:

Бредятина
Разумеется такой идиот, как я, может рассуждать только на уровне детского сада)))
11 июн 13, 12:58    [14420039]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11465
U-gene
Очень умная фраза. Теперь остается выяснить, как же оно меняет семантику и при чем здесь исскуственный интеллект. :)
Если вспомнить классику ООП, то объект - нечто, умеющее принимать и посылать (возможно) типизированные сообщения. И есть три принципа - инкапсуляция, наследование и полиморфизм. Первое - закрывает доступ к реализации объекта, второе - определяет связи между объектами в виде ориентированного графа, третье задаёт "принцип замены" - потомок может использоваться везде, где может использоваться предок.
Разумеется, соображения практической полезности и эффективности реализации влияют на многое: инкапсуляция - не особо жёсткая, в графе наследований могут быть (сложные) циклы, ну и с заменой - тоже не всё гладко.
Так вот в модели ООП нет массы вещей, которые есть и необходимы для эффективной реализации реляционного хранилища. Необходимы настолько, что вы не можете отказаться ни от первичных ключей, ни от ссылочных ограничений, ни от многих других вещей. Вещей, о которых можно просто не думать, если выбрать другой способ реализации постоянства.
Вы уже планируете добавать в RxO различные "реляционные расширения", а в результате получите тот самый гибрид с корнями капусты и листьями редьки.
И окажется, скорее всего, что те задачи, которые эффективно решает RxO, не менее эффективно могут быть решены чем-то вроде комбинации SQL Developer/JDeveloper. Только в этой связке и проблемы со стороны СУБД и проблемы со стороны прикладного кода могут быть решены с максимально возможной эффективностью, а в случае RxO придётся решать задачу преодоления ограничений инструмента.
11 июн 13, 15:59    [14421454]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
Так вот в модели ООП нет массы вещей, которые есть и необходимы для эффективной реализации реляционного хранилища. Необходимы настолько, что вы не можете отказаться ни от первичных ключей, ни от ссылочных ограничений, ни от многих других вещей. Вещей, о которых можно просто не думать, если выбрать другой способ реализации постоянства.
Что и требовалось доказать. В презентация определяются ключи (в т.ч. внешние) между классами, и, далее, говорится о том, что ничто не мешает определять внешние ключи между классами и таблицами. Вы просто не не в курсе темы, на которую пытаетесь разговаривать.

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

Basil A. Sidorov
И окажется, скорее всего, что те задачи, которые эффективно решает RxO, не менее эффективно могут быть решены чем-то вроде комбинации SQL Developer/JDeveloper. Только в этой связке и проблемы со стороны СУБД и проблемы со стороны прикладного кода могут быть решены с максимально возможной эффективностью, а в случае RxO придётся решать задачу преодоления ограничений инструмента.
Я выделил среди всего этого, фразу "скорее всего". То есть всё это - лишь бездоказательные домыслы. Для того, что бы что то доказать, Вам придется изучить. Для этого Вам придется отказаться от нескольких стереотипов (например, противопоставление "прикладной код vs. СУБД"). А отказавшись, Вы увидите, насколько ни о чем, то , что Вы здесь написали.
11 июн 13, 17:09    [14421952]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина
Спасибо. Но это не проясняет суть. Если вместо РМД в РСХОД используется модель EAV, то данные все равно ведь хранятся в РБД в виде хранимых отношений)) Так? Уточните, пожалуйста, на простом П1.
Уже уточнял на чем то другом - 14408866. Можно еще здесь почитать о деталях.
Бредятина
Поэтому РМД и не применима сама по себе.
Да тьфу ты ) Вот же заладил! Применима она. Только применять ее нужно как модель данных (значений), а не модель предметной области (значений с семантической нагрузкой).


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

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

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 , то у Алгебры что- то другое.
11 июн 13, 17:39    [14422108]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11465
U-gene
А отказавшись, Вы увидите, насколько ни о чем, то , что Вы здесь написали.
Мы эксплуатируем приложение, где уже было два инцидента связанные со вполне безобидной, вроде бы, вещью - созданием (в базе) сессий и отслеживанием их активности.
Так вот, разбираясь с другой проблемой, я наткнулся, на кусок кода, отвечающий за это самое создание сессий. Вполне правильный:
1. Берём соединение из пула;
2. Препарируем запрос;
3. Исполняем параметризованный запрос;
4. Возвращаем соединение в пул.
Каждый этап в отдельности - совершно правилен, логичен и объясним. "Best practics" и всё такое.
Проблема в том, что под реальной нагрузкой в не очень большой системе оно не масштабируется.
Решение, которое делаете вы будет ровно таким же "good enough".
Особенно, когда закончится фан собственно разработки и начнётся мутотень исправления ошибок.
11 июн 13, 19:00    [14422386]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

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

Что такое "созданием (в базе) сессий"? Дайте кусок кода, пару строк.:)
11 июн 13, 19:53    [14422615]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 9 [10] 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить