Допустим, я храню продукты и поставщиков в базе данных NoSQL. Каждый поставщик может продать несколько продуктов, но каждый продукт может быть продан только одним поставщиком.
Оба ссылаются друг на друга:
Product
{
Id: 1,
Name: "Product A",
SupplierId: 123,
SupplierName: "Hees"
}
Поле «SupplierName» может показаться «избыточным», но я хочу избегать объединений, поэтому мое приложение позаботится об этом.
Supplier
{
Id: 123
Name: "Hees",
Products: [1, 2, 3]
}
Теперь мое приложение должно позаботиться о том, чтобы ссылки были действительными.
Допустим, продукты уже есть в базе данных без каких-либо поставщиков.
Теперь функция addSupplier должна добавить нового поставщика и выполняет следующие действия:
- Вставка нового объекта поставщика в базу данных
- Все продукты из массива "Products" должны быть обновлены: SupplierName и SupplierId должны быть обновлены.
Я борюсь с вопросом, должен ли второй пункт быть частью моей базы данных или бизнес-логики.
У меня есть два варианта:
Моя бизнес-логика будет просто вызывать тупую логическую функцию базы данных «InsertSupplier (...)», которая будет возвращать идентификатор нового поставщика. Затем он будет вызывать функцию базы данных «UpdateProduct (...)» для каждого продукта, который содержал поставщик.
Моя бизнес-логика просто вызовет «InsertSupplier (...)» в логике базы данных, и DAL позаботится об обновлении ссылок.
Я привык к SQL, где эталонная логика всегда обрабатывалась базой данных и была проблемой базы данных.
Но моя интуиция говорит, что «каждый продукт должен иметь идентификатор поставщика и имя поставщика» - это бизнес-логика.
Что ты думаешь?