将 Java 中的购物篮存储为数据库中的 Blob...或者不存储？
因此，我正在开发一个需要持久购物篮的购物篮应用程序，并尝试决定是将我的购物篮/商品作为 blob 存储在数据库中还是将它们分成多个表（*例如 - tbl_basket、tbl_basket_items、tbl_basket_item_variants* ）。我不需要对购物篮中的物品进行排序或过滤。我将简单地根据 sellto 查询篮子（顺便说一句，每个 sellto 可能有多个篮子）。购物篮的有效期相对较短（最多 6-12 个月）。他们可能有数百个行项目（极少数情况），但我不认为任何东西都那么大，以至于会降低性能。用户数量相对较少...最多 400 个并发用户。典型使用量约为 50-100 个并发用户。
我倾向于简单地将我的篮子存储为一个斑点，只是因为它简单且相对干净（是的，我很懒）。我的问题是，我错过了什么吗？这种方法有什么缺点。有什么好处？我想到的一个缺点是，如果我的篮子对象发生变化，这可能会成为活动篮子的问题。
感谢您提供的任何见解。
So I'm working on a shopping basket application that requires a persistent basket and am trying to decide whether to store my basket/items as a blob in the database or break them out into multiple tables (*e.g. - tbl_basket, tbl_basket_items, tbl_basket_item_variants*). I have no need for sorting or filtering of basket items. I will simply query the basket based on soldto (btw, there could be multiple baskets per soldto). Baskets will only be valid for a relatively short period of time (6-12 months max). They could have several hundred line items (rare case), but I don't expect anything really all that big that it would degrade performance. The number of users is relatively small...400 concurrent users max. Typical usage would be somewhere around 50-100 concurrent users.
I'm leaning towards simply storing my basket as a blob simply because it's simple and relatively clean (yes I'm lazy). My question is, am I missing something? What are the drawbacks to this approach. What are the benefits? The one drawback that comes to mind is if my Basket object changes, it could be a problem for active baskets.
Thanks for any insight you might have.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用篮子、篮子项目表模式，并为数据库不透明数据（例如图像、文档等）留下 blob。最终，您将希望将篮子项目与库存控制或分析或......联系起来，并将该数据存储在blob 会降低性能。
use a basket, basket_item table pattern, and leave blobs for database opaque data like images, documents, etc.. Eventually you will want to tie basket items to inventory control, or analytics, or...., and having that data in a blob will kill performance.
不要存储在块中。今天不需要排序或过滤并不意味着明天、下周或下个月不需要排序或过滤。此外，您将更好地保护自己免受变化的影响；使用 blob 意味着根据需求的变化转换为新格式的额外工作。
现在以正确的方式进行操作将为您节省将来大量的工作。
Don't store in a blob. Because you don't need to sort or filter today doesn't mean you won't tomorrow or next week or next month. Also, you'll be protecting yourself much better against change; using a blob means extra work converting to new formats as needs change.
Doing it the correct way now will save you tons of work in the future.
在这里做你想做的事并没有什么本质上的错误。您基本上存储一个编码为二进制数据并可通过单个键检索的哈希表（或对象或属性列表）。当然，这将使通过其他字段查询变得更加困难，但如果您确定不需要它，那么就继续吧。
您提出的解决方案基本上就是为什么有些人更喜欢“对象数据库”而不是关系数据库的原因。它们使存储物品变得非常容易！
There is nothing inherently wrong with doing what you want to do here. You are basically storing a hash table (or an object, or a property list) encoded as binary data and retrievable by a single key. It will make it harder to query by other fields of course, but if you are sure you don't need that then go ahead.
The solution you are proposing is basically why some people prefer "object databases" to relational ones. They make it very easy to store objects!
从各个角度来看，使用
blob都是个坏主意您会搬起石头砸自己的脚如果您使用
blob并为以后的漫长（可能是痛苦的）重新设计做好准备。Using a
blobis bad idea from various points of viewYou'd be shooting yourself on the foot if you use
blobsand setting yourself up for a lengthy (probably painful) re-design later on.你的数据库中最好不要有“智能列”。它们应该只是数据，这就是数据库的用途。
智能列是一些需要进一步处理才能使用的列，例如：A1234 => A代表男性，1234是序列号。
更不用说您的“blob”购物车，它比之前的示例“更智能”。
请参阅 http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-设计/dp/0321293533
You better don't have a "smart column" in your database. They are supposed to be just data, this is what database for.
Smart column is some column which need further processing to make use of it, e.g.: A1234 => A represent male, and 1234 is the serial number.
Not to mention your "blob" shopping cart, which is way "smarter" than the example before.
refer to http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533