D7 ORM - ON DELETE CASCADE

Рейтинг: 18.5172  
Новая
Предложил Николаев Андрей 09.01.2017 11:41:05

D7 ORM - ON DELETE CASCADE

Идея, которую хотелось бы тут изложить, не нова, но руки никак до нее не доходили.
Навеяна она сообщением на форуме: http://dev.1c-bitrix.ru/community/forums/forum6/topic92353/

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

Рейтинг: -0.0688  
Кирсанов Анатолий 20.01.2017 06:52:37
Сколько существует Битрикс, столько будоражит воображение разработчиков возможность перенести часть API на уровень СУБД.

Не будет такого. Битрикс API (серверное) написано на PHP. Так что каскадов ждать не надо.
Рейтинг: 0  
Николаев Андрей 20.01.2017 08:12:31
А причем тут php и Битрикс когда мы говорим про ORM. Если Битрикс хочет - он может это не использовать, но две лишних строчки в sql это минус 10 строчек кода и транзакция, что упростит написание кода, и позволит поддерживать ссылочную целостность бд.

к тому же это не перенос API в БД, т.к. все те же методы останутся, просто для удаления связей не нужно будет вызывать 100-500 функций в транзакции
Рейтинг: 0  
Кирсанов Анатолий 20.01.2017 15:32:19
А причем тут php и Битрикс когда мы говорим про ORM.
При том, что ORM - серверное API Битрикс. Для удаления строк предусмотрены события, которые должны отработать. Если их не будет в PHP (на каскадном удалении на уровне СУБД не будет), то не будет и реакции.
Рейтинг: 0  
Николаев Андрей 20.01.2017 15:44:01
Суть в следующем: то что может и хорошо делает СУБД должна делать СУБД.
Да, всю логику выносить туда бессмысленно, но есть базовые операции, которые она умеет делать хорошо.
Каскадные операции это то же что и JOIN. Вы же не делаете JOIN средствами PHP ?  
Рейтинг: 0  
Кирсанов Анатолий 20.01.2017 17:04:41
Каскадные операции это то же что и JOIN.
Определенно не тоже. Битрикс действительно использует для выборки всю мощь SQL. Но не верю, что станет это делать для каскадных операций. Может быть и станет когда-нибудь, но после жесткой привязки к одной СУБД. Но и этого будет мало, т.к. обработчики событий придется повторять и согласовывать (как?) на двух уровнях. Если только триггеры и хранимые процедуры удастся писать на PHP (используя API Битрикс) ... Все на свете когда-нибудь происходит. Может и это случится.

Вы же не делаете JOIN средствами PHP ?
Как Вам сказать ...

Для выборки одного логически связанного набора данных частенько приходится использовать несколько вызовов API Битрикс (в том числе с целью соединений). А это, несомненно, несколько разных запросов. Так что да, ответ утвердительный.

Более того, часто случается так, что один навороченный запрос будет выполняться в десятки раз дольше пары-тройки более простых (приводящих к соединению средствами PHP).

Возможно, когда ORM станет полноценным (видимо, объектным), эти выкрутасы будут скрыты внутри API Битрикс и достаточно будет одного вызова. Но пока так. И сколько это продлится в годах - не знаю.

то что может и хорошо делает СУБД должна делать СУБД.
Это философский вопрос. Очень похож на расхожую и также неочевидную фразу из-за бугра - "каждый должен заниматься своим делом".
Рейтинг: 0  
Николаев Андрей 20.01.2017 17:07:38
Анатолий, я же не предлагаю переписывать событийную модель Битрикса, не предлагаю отказаться от событий. Я просто хочу, чтобы для реализации ORM, т.е. своих кастомных таблиц, я мог бы использовать каскады.
Рейтинг: -0.8249  
Кирсанов Анатолий 20.01.2017 17:09:08
Я просто хочу, чтобы для реализации ORM, т.е. своих кастомных таблиц, я мог бы использовать каскады.
Я не хочу нарваться на модуль, за который заплатил клиентские деньги, и узнать, что он написан так, как предлагаете Вы. Боже упаси.
Рейтинг: 2.0688  
Николаев Андрей 20.01.2017 17:21:07
Во-первых, покупая модуль Вы покупаете решение определенной задачи. Как ее решал разработчик, это не тот вопрос, который нужно знать клиенту. Либо Вас он устраивает и Вы платите деньги, либо нет. Пример следующий: Вам нужен модуль, который раз в сутки запрашивает погоду с яндекса и выводит ее в компоненте. Как он делает запрос и хранит данные Вас с точки зрения клиента не должно волновать (Я имею ввиду - будет ли запрос rest или soap, а не о факте запроса впринципе или какие-то прокси).

Во-вторых, мое субективное мнение, что Вы не работали на проектах, где таких "misc" таблиц много и по невнимательности разработчика или каких-либо внешних факторов они распухают.

В-третьих, хотите ли Вы нарваться на такой модуль или нет, это сугубо Ваши предпочтения. Мне вот лично это важнее чем "видеофиксирование переговоров" в Б24, но опять же - это мое личное мнение, так же как и Ваше отношение к каскадам - Ваше мнение.

Если Вы знаете отличия каскадных операций на MSSQL, Oracle и MySQL, я был бы благодарен, если бы Вы поделились этой информацией.
Рейтинг: -0.8249  
Кирсанов Анатолий 20.01.2017 17:49:55
покупая модуль Вы покупаете решение определенной задачи. Как ее решал разработчик, это не тот вопрос, который нужно знать клиенту.
Ровно до тех пор, пока не приходится покупку расширять. А там и не было предусмотрено ничего для расширения. Событий то нет. В таком случае - только кастомизация модуля (!) и потеря последующих обновлений.

Хотя при таком подходе автор решения будет рекомендовать лезть напрямую в таблицы ... Что в принципе в Битрикс не приветствуется (граничит с профнепригодностью такой прием).

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

Здесь консенсуса не будет. Эмоции не помогут. Только голосование. Ну, наголосуют, что это круто. Да до такой степени, что контора возьмет под козырек, тогда появится Битрикс SQL (как когда-то на .Net делали).

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