ЕК
Понял. Я думал услышать о приросте производительности, а тут такое... Вопрос снят. Я так понял, единственное для чего нужны - триггерить события на связанные записи
Таблички джойнить
Size: a a a
2020 February 12
A
Таблички джойнить
Ну на джойне табличек есть прирост производительности в больших агрегированных выборках? Если нет, то как выше Игорь сказал только для целкостности
ЕК
всякие cascade delete, типа, чтоб не было такого что ты юзера удалил, а от него лапша осталась по таблицам
PP
return redirect($payment->getConfirmation()->_confirmationUrl);
A
всякие cascade delete, типа, чтоб не было такого что ты юзера удалил, а от него лапша осталась по таблицам
По мне, так удалять это вообще моветон ))
V
внешние ключи перекладывают часть ответственности за целостность данных на БД, в итоге надо писать и поддерживать меньше кода.
RK
лучше всего softdelete и cascade update без cascade delete
ЕК
По мне, так удалять это вообще моветон ))
Ну не всегда и не всё)
Сущности типа товаров-пользователей-заказов — удалять не надо, разумеется, есть софтДелетес, а всякую аналитику, например, от заказа, если он "проведён" в терминах 1с, а потом отменили проведение?
Сущности типа товаров-пользователей-заказов — удалять не надо, разумеется, есть софтДелетес, а всякую аналитику, например, от заказа, если он "проведён" в терминах 1с, а потом отменили проведение?
RK
cascade delete правильно написали опасная тема
A
Ну не всегда и не всё)
Сущности типа товаров-пользователей-заказов — удалять не надо, разумеется, есть софтДелетес, а всякую аналитику, например, от заказа, если он "проведён" в терминах 1с, а потом отменили проведение?
Сущности типа товаров-пользователей-заказов — удалять не надо, разумеется, есть софтДелетес, а всякую аналитику, например, от заказа, если он "проведён" в терминах 1с, а потом отменили проведение?
Новое событие отмены проведения и меняем стэйт заказа
RK
намудришь ченить и пол базы улетит))
ЕК
Новое событие отмены проведения и меняем стэйт заказа
Я имею в виду случаи, когда мы идём на сознательную денормализацию базы
таблица "состояние заказов", в ней ид товара, номер строки заказа, статус обеспечения, например, дата прихода товара на склад, что-то такое, ну дата-номер заказа
Чтобы строить именно по этой табличке отчёт, без фигни
таблица "состояние заказов", в ней ид товара, номер строки заказа, статус обеспечения, например, дата прихода товара на склад, что-то такое, ну дата-номер заказа
Чтобы строить именно по этой табличке отчёт, без фигни
ЕК
При "проведении" заказа делаем в эту таблицу записи, при отмене — бахаем их
A
намудришь ченить и пол базы улетит))
Да, Роман, про каскады и все подобное я в курсе. Меня как раз вопрос КПД интересовал. Базы большие, аналитику большую собирать нужно, поэтому вопрос производительности висит остро
A
При "проведении" заказа делаем в эту таблицу записи, при отмене — бахаем их
Да, я понял. Это уже скорее вопрос бизнес логики и вкуса, как решать задачу.
ИЛ
Да, Роман, про каскады и все подобное я в курсе. Меня как раз вопрос КПД интересовал. Базы большие, аналитику большую собирать нужно, поэтому вопрос производительности висит остро
Юзай NoSQL
ИЛ
Если прям нереально быстрое что-то надо
RK
для статистики большой нормальная тема elk стэк
A
Юзай NoSQL
O_o
ЕК
Ну это вопрос уже быстродействия, в том числе, если у тебя в таблице состояния документов описываются, например, блин
Ну вот давай поговорим про остатки товаров)
Ну вот давай поговорим про остатки товаров)