Хранить корзину покупок в Java как Blob в базе данных ... или нет?

Question

Итак, я работаю над приложением корзины покупок, которому требуется постоянная корзина, и пытаюсь решить, сохранять ли мою корзину / товары в виде большого двоичного объекта в базе данных или разбивать их на несколько таблиц (* например, - tbl_basket, tbl_basket_items, tbl_basket_item_variants *).Мне не нужно сортировать или фильтровать элементы корзины.Я просто сделаю запрос корзины, основанной на soldto ( кстати, может быть несколько корзин на продано ).Корзины будут действительны только в течение относительно короткого периода времени (максимум 6-12 месяцев).У них может быть несколько сотен позиций (редкий случай), но я не ожидаю, что что-то настолько большое, что это ухудшит производительность.Количество пользователей относительно невелико ... 400 одновременных пользователей макс.Типичное использование будет где-то около 50-100 одновременных пользователей.

Я склоняюсь к тому, чтобы просто хранить свою корзину в виде капли просто потому, что она простая и относительно чистая (да, я ленивый).У меня вопрос, я что-то упустил?Каковы недостатки этого подхода.Каковы преимущества?Единственный недостаток, который приходит на ум, это то, что если мой объект Корзина изменится, это может стать проблемой для активных корзин.

Спасибо за любые ваши идеи.

Answer 1

используйте корзину, шаблон таблицы basket_item и оставляйте большие двоичные объекты для непрозрачных данных базы данных, таких как изображения, документы и т. Д. В конечном итоге вы захотите привязать элементы корзины к управлению запасами, или аналитике, или ...., и, имея этоданные в BLOB-объекте снижают производительность.

Answer 2

Использование blob - плохая идея с разных точек зрения

1. Капли работают медленно, де-сериализация вашей корзины будет очень медленной, и вам, вероятно, придется это сделатьна каждом просмотре страницы для каждого клиента (для отображения количества товаров или полного мини-виджета с содержимым корзины)
2. Забота о будущем, я знаю, что мы не должны чрезмерно проектировать наши решения и пытаться придерживаться принципа YAGNIвсегда помните, но я гарантирую вам, что в конечном итоге бизнес захочет что-то сделать с вашими сохраненными корзинами, такими как анализ оставленных тележек, товаров, которые чаще всего добавляются в тележки, средняя стоимость корзины, среднее количество товаров на корзину и т. д. и т. д.и т. д.,

Вы бы застрелились на ноге, если использовали blobs, а позже настроились на длительный (возможно, болезненный) перепроектирование.

Answer 3

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

Решение, которое вы предлагаете, заключается в том, почему некоторые люди предпочитают «объектные базы данных»реляционные.Они позволяют очень легко хранить предметы!

Answer 4

Не хранить в капле. Потому что вам не нужно сортировать или фильтровать сегодня, это не значит, что вы не будете делать это завтра, на следующей неделе или в следующем месяце. Кроме того, вы будете намного лучше защищать себя от перемен; использование BLOB-объектов означает дополнительную работу по преобразованию в новые форматы по мере необходимости.

Если вы сделаете это правильно сейчас, вы сэкономите массу работы в будущем.

Answer 5

Вам лучше не иметь «умный столбец» в вашей базе данных.Предполагается, что это просто данные, для этого и нужна база данных.

Умный столбец - это столбец, который нуждается в дальнейшей обработке, чтобы использовать его, например: A1234 => A представляет собой мужской, а 1234 - серийный номер,Не говоря уже о вашей корзине покупок «blob», которая «умнее», чем в предыдущем примере.

см. http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533