угу. и на фронте сайта ты будешь продавать упаковку. я ждал такого аргумента - накостылять просто, а разработать схему сложнее.
не знаю, ты наверное плохо прочел меня - или что-то другое принципиально отличающееся от обычного продукта
угу. и на фронте сайта ты будешь продавать упаковку. я ждал такого аргумента - накостылять просто, а разработать схему сложнее.
не знаю, ты наверное плохо прочел меня - или что-то другое принципиально отличающееся от обычного продукта
zelenin, я вас прекрасно понял, пожалуйста потерпите, пусть каждый сначала представит свое решение, в т.ч. и вы если хотите, но без комментариев
Для чего-то другого принципиально(!) отличающегося всегда можно сделать отдельную таблицу.zelenin писал(а): ↑2018.03.16, 20:00угу. и на фронте сайта ты будешь продавать упаковку. я ждал такого аргумента - накостылять просто, а разработать схему сложнее.
не знаю, ты наверное плохо прочел меня - или что-то другое принципиально отличающееся от обычного продукта
для элемента заказа? зачем?anton_z писал(а): ↑2018.03.17, 00:31Для чего-то другого принципиально(!) отличающегося всегда можно сделать отдельную таблицу.
но я не про элемент заказа. я указывал именно на то, что элемент заказа в схеме может быть только продуктом и не может быть чем-то кроме продукта.
Это можно сделать добавив еще внешних ключей в элемент заказа - некоторые ключи будут NULL. Чтобы избежать последнего можно на каждую таблицу с чем-то продаваемым, добавить свою таблицу элементов заказа. Можно еще типизацию элемента ввести, но это решение мне не очень нравится. так как не сделаешь FOREIGN KEY RESTRICTION.zelenin писал(а): ↑2018.03.17, 00:55 но я не про элемент заказа. я указывал именно на то, что элемент заказа в схеме может быть только продуктом и не может быть чем-то кроме продукта.
Нужно отличать элементы заказа от сущностей, их порождающих. очевидно, что у порождающих сущностей есть отдельные таблицы (product, service, product_kit etc) - это не нуждается в проговаривании. Нужно было лишь расширить таблицу заказов для поддержки нескольких типов сущностей.
поясни. вот у тебя таблицы из той схемы:anton_z писал(а): ↑2018.03.17, 01:04Это можно сделать добавив еще внешних ключей в элемент заказа - некоторые ключи будут NULL. Чтобы избежать последнего можно на каждую таблицу с чем-то продаваемым, добавить свою таблицу элементов заказа. Можно еще типизацию элемента ввести, но это решение мне не очень нравится. так как не сделаешь FOREIGN KEY RESTRICTION.zelenin писал(а): ↑2018.03.17, 00:55 но я не про элемент заказа. я указывал именно на то, что элемент заказа в схеме может быть только продуктом и не может быть чем-то кроме продукта.
Нужно отличать элементы заказа от сущностей, их порождающих. очевидно, что у порождающих сущностей есть отдельные таблицы (product, service, product_kit etc) - это не нуждается в проговаривании. Нужно было лишь расширить таблицу заказов для поддержки нескольких типов сущностей.
order_product(order_id, product_id, price, qty)
ну отличаться они могут только наличием fk на разные таблицы, в чем есть плюс, но на мой взгляд меньший, чем лаконичная схема.
У меня можно сделать целостность на уровне ссылок, прописав ограничения внешнего ключа явно с помощью ADD CONSTRAINT и им подобных.
я на это указал выше. Это не недостаток, если целостность гарантируется на уровне приложения.
это бизнес-знание - тип лежащей в заказе сущности. Указывает оно на местоположение данных или на специфический обсчет элемента заказа - собственно решать приложению.
плюсы и минусы известны. вынося защиту целостности в приложение, более компактная схема предпочтительнее, чем дублирование таблиц.anton_z писал(а): ↑2018.03.17, 01:54Еще кое-что по этой теме: https://www.slideshare.net/billkarwin/s ... ant_make_a