Комментарии 18
Мне кажется под реализацию этого может подойти MongoDb
Ну и чем вам плоха реляционная модель? Стройте на ее основе прототипную, никто не заставляет вас городить вспомогательных сущностей, например, для реализации связей «многие-ко-многим» если можно обойтись без них. Зато если «прототипная» модель вдруг не справится с задачей, легко будет «выйти за рамки» за счет реляционности.
В статье не затрагиваются вопросы реализации модели. Для реляционной, иерархической, документной есть свои СУБД. На реляционной можно и иерархию сделать, и объектную, и любую другую. Также и на документной и на иерархической. Вопрос в практичности. Для прототипной нет родной субд, поэтому её реализация на других потянет за собой их особенности.
Мною реализована эта модель на реляционной, и, к примеру, приходится придумывать трюки для работы с иерархией, с представлением неограниченных по длине и типу значений. Чем плоха иерархия в реляционной? Сделать можно, но она для этого не предназначена, приходится хранить и работать с специальными для этого данными: мат. путями, например. А как представить любого типа значение в одной колонке? Можно использовать строки, но тогда проявляются особенности сортировки по числам, работе с датами и индексированием таблиц. Или на каждый возможный тип делать свои колонки, отдельные таблицы…
Мною реализована эта модель на реляционной, и, к примеру, приходится придумывать трюки для работы с иерархией, с представлением неограниченных по длине и типу значений. Чем плоха иерархия в реляционной? Сделать можно, но она для этого не предназначена, приходится хранить и работать с специальными для этого данными: мат. путями, например. А как представить любого типа значение в одной колонке? Можно использовать строки, но тогда проявляются особенности сортировки по числам, работе с датами и индексированием таблиц. Или на каждый возможный тип делать свои колонки, отдельные таблицы…
Мы как раз занимаемся чем-то вроде создания СУБД с нереляционной моделью (не уверен насчет прототипной или нет, т.к. появляются классы и метаклассы, но они очень похожи на прототипы). В основе у нас лежит key-value хранилище (Voldemort) и Hadoop. Так что можем обменяться некоторыми идеями, если интересно.
А какая цель класса? Объекты у вас отличаются своим внутренним строением?
По сути у меня нет, ни объектов, ни классов. Моя модель совпадает с моделью RDF триплетов: субъект предикат объект. Триплеты в свою очередь образуют узлы гиперграфа. Некоторые узлы в нашей модели мы называем сущностями (аналог объекта, но не совсем объект, поскольку нет понятных границ объекта, а сущность слово хорошее, которое к тому же не создает в нашей системе многозначности). Например, какой-то конкретный человек (например клиент) Вася Пупкин — это сущность, в то время, как число 42 будет являться узлом, но при этом не будет являться сущностью. И, получается, что у некоторых сущностей долны быть, какие-то связи, а у других нет, и должны быть какие-то другие сущности, которые описывают какие связи у каких сущностей должны быть (аналог классов и метаклассов). Если использовать пример с Васей Пупкиным, нужен способ сказать что Вася клиент, а поскольку Вася клиент, он должен был что-то у нас купить. На основе этих сущностей-классов, например, можно строить форму для ввода данных.
НЛО прилетело и опубликовало эту надпись здесь
То что Вы написали мне очень напомнило описание сетевых или иерархических баз данных, где схожие проблемы при модификации данных, что и в Вашей статье. Из этого смею предположить, что подобное было реализовано, например:
И соответственно, возможно узнать о неких «подводных камнях» в будущем проекте.
А так идея интересная, желаю набрать команду и удачи!
- ИСУБД CronosPRO
- СООБЗ Cerebrum
- Caché
И соответственно, возможно узнать о неких «подводных камнях» в будущем проекте.
А так идея интересная, желаю набрать команду и удачи!
Я приблизительно по схожей теме защитил магистерскую и баколаврскую. Только у меня были не прототипы, а «специализации», позволяющие наследование между «составными» объектами (не обязательно одинаковых «классов») и изменение значение атрибутов/связей на произвольном уровне вложенности (например, при наследовании схем баз данных поменять тип поля произвольной таблицы). Так вот, прототипирование для этого совсем не нужно, все прекрасно реализуется в рамках классической ОО парадигмы. Нужно только правильно классифицировать связи и ввести более общее понятие наследования.
В прототипной модели нет самостоятельного понятия «прототип». Прототипом может быть любой объект. Это всего лишь терминология, чтоб обозначить роль объекта в конкретной рассматриваемой ситуации. У нас только объекты. Я скажу обратное, нам не нужны классы, чтоб творить ) Классы скорее нужны там, где важна стандартизация и запрет выхода за её границы, и в программном обеспечении это редко оправдано в виду его частого изменения, необходимости расширения функциональности, изменения стандартов деятельности, где программа внедрена. В итоге классы на порядок усложняются, придумываются примеси, динамические вызовы методов, свойства, модификация во время выполнения – процесс от обратного, сначала запретить/ограничить, а потом разрешать.
Приятно удивлен, что по этой теме диссертацию защищают. :)
Приятно удивлен, что по этой теме диссертацию защищают. :)
>Прототипом может быть любой объект.
Да, я понимаю. Я когда исследованием на этой почве занимался, довел идею прототипов до абсолютного предела: в одной из моих метаязыков я убрал не только понятие «класс», но и понятие «тип», определил порядок на значениях так, что значение стало сужением типа. То есть 3 и int были объектами одного рода. Меня просто всегда привлекала построение систем с минимальным числом базовых сущностей.
>В итоге классы на порядок усложняются
Да ничего подобного, вы просто узко смотрите на понятие класс — на самом деле разницы между традиционной классовой моделью и прототипной не так много. Просто посмотрите на реализцую ООП в языках отличных от С++/Java — в той же скале можно добавлять атрибуты/методы прямо в экземпляр класса прямо при описании конкретного инстанса без проблем, при этом оставаясь в пределах статической типизации.
Я просто очень не люблю динамическую типизацию, а ваше описание прототипов именно в духе динамической типизации. А как показывает практика гибкость прототипов прекрасно реализуюется в классовой модели, при этом сохраняя все преимущества классовой.
Да, я понимаю. Я когда исследованием на этой почве занимался, довел идею прототипов до абсолютного предела: в одной из моих метаязыков я убрал не только понятие «класс», но и понятие «тип», определил порядок на значениях так, что значение стало сужением типа. То есть 3 и int были объектами одного рода. Меня просто всегда привлекала построение систем с минимальным числом базовых сущностей.
>В итоге классы на порядок усложняются
Да ничего подобного, вы просто узко смотрите на понятие класс — на самом деле разницы между традиционной классовой моделью и прототипной не так много. Просто посмотрите на реализцую ООП в языках отличных от С++/Java — в той же скале можно добавлять атрибуты/методы прямо в экземпляр класса прямо при описании конкретного инстанса без проблем, при этом оставаясь в пределах статической типизации.
Я просто очень не люблю динамическую типизацию, а ваше описание прототипов именно в духе динамической типизации. А как показывает практика гибкость прототипов прекрасно реализуюется в классовой модели, при этом сохраняя все преимущества классовой.
Абсолютный предел до каких последствий довел? Меня тоже привлекает минимальное число базовых сущностей. В своём проекте применял классы и другие метаданные, но с метаданными приходится сталкиваться не только мне, как программисту, но и пользователям системы. В прототипной модели вижу гораздо больше гибкости и простоты, так как пользователи могут создавать сразу нужные объекты без необходимости предварительно создавать метаданные (классы).
Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности. Проверка принадлежности к классу равносильна проверке наследования объекта. Какие вы видите преимущества у классовой модели? Думаю, они могут проявляться на конкретной задаче, но не во всём.
Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности. Проверка принадлежности к классу равносильна проверке наследования объекта. Какие вы видите преимущества у классовой модели? Думаю, они могут проявляться на конкретной задаче, но не во всём.
>Абсолютный предел до каких последствий довел?
До уровня proof-of-concept. «Оно, может, и умно, но больно непонятно. Над вами потешаться будут». Тоесть в качестве ресерча — было прикльно, а рассказать простым людям что понятие число и конкретное число вещи мало реально.
>Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности.
Да я и написал потому «в духе». Все равно пользователь формирует свой язык: «Юр лицо», «Контрагент», «Прайс лист» и различает их от конкретного контрагента. Причем классовая модель добавить лишних полей конкретному контрагенту никак не запрещает.
Вообще я работал не в области баз данных а MDD и на основе описания языка я автомаически генерил редакторы к этим языкам, валидацию и т.д. С «динамическим» прототипированием так не выйдет. При этом язык можно редактировать параллельно с моделями, так что никакой сложности с изменениями базовой структуры нет.
До уровня proof-of-concept. «Оно, может, и умно, но больно непонятно. Над вами потешаться будут». Тоесть в качестве ресерча — было прикльно, а рассказать простым людям что понятие число и конкретное число вещи мало реально.
>Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности.
Да я и написал потому «в духе». Все равно пользователь формирует свой язык: «Юр лицо», «Контрагент», «Прайс лист» и различает их от конкретного контрагента. Причем классовая модель добавить лишних полей конкретному контрагенту никак не запрещает.
Вообще я работал не в области баз данных а MDD и на основе описания языка я автомаически генерил редакторы к этим языкам, валидацию и т.д. С «динамическим» прототипированием так не выйдет. При этом язык можно редактировать параллельно с моделями, так что никакой сложности с изменениями базовой структуры нет.
С динамичностью мы вроде поняли другу друга. Какой же существенный плюс дает использование классов?
В моих задачах по управлению содержимым назначение класса может быть дословным – для классификации данных, при этом не данные определяются классом, а класс возникает от соответствующих данных для последующего осмысления данных на более высоком уровне. Поэтому в качестве базовой сущности класс не нужен.
В моих задачах по управлению содержимым назначение класса может быть дословным – для классификации данных, при этом не данные определяются классом, а класс возникает от соответствующих данных для последующего осмысления данных на более высоком уровне. Поэтому в качестве базовой сущности класс не нужен.
Уточню. В моей модели типизация получается динамической, так как одной базовой сущностью нужно уметь представлять разные значения. Но применение классов не решает вопрос динамичности/статичности. Если нужна гибкость, мы в любом случаи придем к динамической типизации, например, её имитацией. Прототипную модель реализовывал в реляционной базе, на её статической типизации имитировал динамическую ради гибкости. А что даст классовая модель?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прототипная модель данных