-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
YiiFramework Yii PHP framework 2 public preview
- Автор темы Ragazzo
- Дата начала
у текущей реализации AR с NoSQL есть концептуальная проблема: для формирования запросов юзается схема, и это захардкодено,
https://github.com/yiisoft/yii2/blob/master/framework/yii/db/ActiveRecord.php#L379
https://github.com/yiisoft/yii2/blob/master/framework/yii/db/ActiveQuery.php#L157
а привычной схемы с PK, FK и скалярами в NoSQL концептуально нет, там документы с произвольной структурой и вложенностью;
надо вводить отдельный уровень абстракции вроде "источника данных", который может юзать схему, а может и не юзать.
можно попробовать сделать для NoSQL эмуляцию схемы, но это будет хрень
или можно предложить разработчикам самим писать схему ORM для NSQL-хранилища вместо автогенерации, но чтобы описать вложенность и наследование документов будет нужен собственный макро-язык,
https://github.com/yiisoft/yii2/blob/master/framework/yii/db/ActiveRecord.php#L379
https://github.com/yiisoft/yii2/blob/master/framework/yii/db/ActiveQuery.php#L157
а привычной схемы с PK, FK и скалярами в NoSQL концептуально нет, там документы с произвольной структурой и вложенностью;
надо вводить отдельный уровень абстракции вроде "источника данных", который может юзать схему, а может и не юзать.
можно попробовать сделать для NoSQL эмуляцию схемы, но это будет хрень
или можно предложить разработчикам самим писать схему ORM для NSQL-хранилища вместо автогенерации, но чтобы описать вложенность и наследование документов будет нужен собственный макро-язык,
Вообще, как минимум для mongodb понятия PK и FK прекрасно мапятся на ObjectID и DBRefs.
Схема же документа и в случае с nosql так или иначе присутствует по факту, просто она более гибкая. Тут скорее надо идти по пути расширения понятия "схема", чем отказываться от схем совсем.
Схема же документа и в случае с nosql так или иначе присутствует по факту, просто она более гибкая. Тут скорее надо идти по пути расширения понятия "схема", чем отказываться от схем совсем.
ну а вроде менять не так много? переименовываем columns в fields, делаем поля-объекты, поля вариантных типов и опциональные поля. для совместимости с РСУБД то, что не укладывается в columns, можно укладывать в json-поле (или если субд не поддерживает - json_encode в text)
fixxxer, Саша, я вот что имею ввиду:
когда РСУБД мапится на объекты, мы можем писать:
Order::find($id)->customer->name
это приводит к 2м запросам по FK или одному с 2мя JOIN,
в sql вариантов структуры данных нет.
при обработке find($id)->customer->name в AR формируется 2 объекта schema, которые парсят "show create table", и по информации о полях и pk строятся SQL-запросы;
вызов sql-ориентированных методов schema захардкоден в самом AR
когда мапится NoSQL, мы не знаем что такое $order->customer->name: обращение ко вложенному документу customer, или фильтрация списка customer, вариантов несколько
чтобы такую ситуацию обработать, нужен макро-язык описания мапинга связей на AR-объекты без имен таблиц, без getPK(), но с поддержкой связи типа вложенность, и совсем другой алгоритм формирования запросов
абстрагироваться от SQL - значит, переписать реализацию AR почти полностью
тут бы или крестик снять и забить на nosql, или вводить DI/абстрактную фабрику, но ни то ни другое великий кормчий делать не захочет
когда РСУБД мапится на объекты, мы можем писать:
Order::find($id)->customer->name
это приводит к 2м запросам по FK или одному с 2мя JOIN,
в sql вариантов структуры данных нет.
при обработке find($id)->customer->name в AR формируется 2 объекта schema, которые парсят "show create table", и по информации о полях и pk строятся SQL-запросы;
вызов sql-ориентированных методов schema захардкоден в самом AR
когда мапится NoSQL, мы не знаем что такое $order->customer->name: обращение ко вложенному документу customer, или фильтрация списка customer, вариантов несколько
чтобы такую ситуацию обработать, нужен макро-язык описания мапинга связей на AR-объекты без имен таблиц, без getPK(), но с поддержкой связи типа вложенность, и совсем другой алгоритм формирования запросов
абстрагироваться от SQL - значит, переписать реализацию AR почти полностью
тут бы или крестик снять и забить на nosql, или вводить DI/абстрактную фабрику, но ни то ни другое великий кормчий делать не захочет
Последнее редактирование:
ну почему без getPK()? его можно и оставить: это либо key в случае key-value, либо ID документа в случае документной базы
а в остальном да, ты прав. Я со своей велосипедоколокольни-то рассуждаю, у меня "ручной" AR с явно написанным SQL (или чем угодно - смотря какой диспетчер запросов) - мне проще
а в остальном да, ты прав. Я со своей велосипедоколокольни-то рассуждаю, у меня "ручной" AR с явно написанным SQL (или чем угодно - смотря какой диспетчер запросов) - мне проще