blocks|key|21641|text|SQL和noSQL数据库有很多不同之处。这些差异使每种存储类型在不同的情况下各有优缺点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|21642|由于这两种数据库类型最终都可以工作，因此这完全取决于上下文或您的实现。|21643|在这个特定的案例(购物车)中，利弊可能都与您的数据的consistency和scalability相关。|offset|length|style|BOLD|21644|noSQL数据库更适合于更“动态”的应用程序(数据分析、IoT、多媒体等)。这类应用程序使用的数据通常没有严格的结构，而且数据量非常大。这意味着不需要开发复杂的数据库模型，并且在单独的“节点”中存储大量数据的成本更低。这也使得noSQL数据库更容易扩展和扩展。主要的问题(缺点)是缺乏结构。这将使您更难运行分析并跟踪数据库的每个细节。|21645|同时，当您的数据结构良好且基本一致时，SQL数据库非常有用(优点)。正如你所知道的，SQL以列和行的形式存储数据，如果你想要生成数据的详细统计数据，或者如果你想要对应用程序中发生的一切进行有组织的记录，这就给了SQL一个优势。主要的缺点(缺点)是SQL数据库的设计需要更多的时间，而且维护SQL数据库可能更昂贵(可伸缩性和物理存储需要更多的硬件)。|21646|从性能上讲，我认为在这个用例中不会有任何重大的区别。|21647|如果你仔细考虑我刚刚写的所有东西，我会说在购物车的上下文中，模型是的方式。购物车不需要大量的升级和更改(可伸缩性)，它的数据总是结构化的(商品名称、价格等)。您可能希望跟踪用户在您的电子商务应用程序中进行的每一笔交易(出于责任和安全原因)。|21648|tl;dr使用SQL是因为购物车使用案例中的数据是结构化的和一致的。|21649|祝好运!|21650|entityMap^0|0|0|Q|B|12|B|0|0|0|0|U|3|0|0|5|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@$F|10|G|11|H|I]|$F|12|G|13|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@$F|18|G|19|H|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@$F|1B|G|1C|H|I]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1D|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|W|$]]

There are many differences between SQL and noSQL databases. Those differences are what gives each storage type its pros and cons on different situations.

Since both database types would work in the end, it all really depends on the context or on your implementation.

In this specific case (shopping cart), the pros and cons are probably all related to the consistency of your data and scalability.

noSQL databses are better (pros) suited for more "dynamic" applications (data analysis, IoT, multimedia, etc.). Such applications use data that usually doesn't have a rigid structure and comes in very large volumes. This means that there's no need to develop a complex database model and it's cheaper to store large amounts of data throughout separate "nodes". This also makes noSQL databases easier to expand and scale. The main problem (cons) is the lack of structure. This will make it harder for you to run analysis and to keep track of every detail of the database.

Meanwhile, SQL databases are useful (pros) when your data is well-structured and mostly consistent. As you know, SQL stores data in columns and rows, this gives SQL an advantage if you want to generate detailed statistics of your data and also if you want to keep an organized record of everything that happens in your app. The main downside (cons) is that the design of an SQL database takes more time and also it's probably more expensive (scalability and physical storage require more hardware) to maintain a SQL database.

Performancewise, I would argue that in this usecase there wouldn't be any major difference.

If you think about all of what i just wrote, I would say that in the context of a shopping cart, the SQL model is the way to go. A shopping cart won't require lots of upgrades and changes (scalability), its data is always structured (name of item, price, etc.) and you might want to keep track of every transaction a user makes in your ecommerce application (for accountability and safety reasons).

tl;dr use SQL because the data in a shoppingcart usecase is structured and consistent.

good luck!

blocks|key|21705|text|像Cassandra和postgres/mysql这样的东西的优缺点大致如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|21706|RDBMS+Cassandra处理多DC高可用性许多better.|21707|Cassandra处理高写入容量许多better.|unordered-list-item|21708|
|21709|Cassandra允许您在不停机的情况下重启主机，因为您将有多个副本(而且您不必担心WAL重放、binlog重放或奇怪的主-主复制问题，尽管一些MySQL和Postgres插件使这一点比过去更容易)。|21710|21711|Cassandra允许您更好地扩展(线性扩展的实例数量高达1200左右，RDBMS允许您通过在现有表中添加索引来随着业务需求的发展而构建查询；Cassandra希望你提前知道查询，并在开始编写data.|21712|21713|MySQL/Postgres之前进行数据建模，这样更容易使用，你会发现大量的库/UI/等可以帮助你获得started|21714|21715|MySQL/Postgres提供真正的事务/+MVCC+-Cassandra的轻量级事务仅限于对单个键的操作，具有更弱的隔离性/原子性保证。|21716|21717|不过，最终，除非您认为购物车将处理数千个并发用户，否则这可能无关紧要(只要您使用的是具有真正数据持久性保证的东西)：使用您最舒适的使用。我会使用Cassandra，因为我非常了解Cassandra，但是如果你对Cassandra+(或者其他什么)不太熟悉，那就用你最了解的吧。|21718|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|11|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|12|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|14|8|@]|9|@]|A|$]]|$1|N|3|H|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|16|8|@]|9|@]|A|$]]|$1|Q|3|H|5|6|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|F|7|18|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1A|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|X|$]]

The general pros/cons of something like Cassandra vs postgres/mysql look like:

<ul>
<li>Cassandra handles multi-DC HA much better.</li>
<li>Cassandra handles high write volume much better.</li>
<li>Cassandra allows you to reboot hosts without downtime because you'll have multiple replicas (and you wont have to worry about WAL replay or binlog replay or weird master-master replication problems, though some RDBMS addons make this easier for MySQL and Postgres than it used to be).</li>
<li>Cassandra allows you to scale better (linear scaling with number of instances up to ~1200 or so instances)</li>
<li>MySQL/Postgres allow you to build queries as your business requirements evolve by adding indices to existing tables; Cassandra expects you to know the queries in advance and do data modeling before you start writing data.</li>
<li>MySQL/Postgres tends to be easier to use, and you'll find a ton of libraries/UIs/etc to help you get started</li>
<li>MySQL/Postgres offer real transactions / MVCC - Casssandra has lightweight transactions limited to operations on a single key with much weaker isolation/atomicity guarantees.</li>
</ul>

Ultimately, though, unless you believe your shopping cart is going to handle thousands of concurrent users, it probably doesn't matter (as long as you use something with real data durability guarantees): use what you're most comfortable using. I'd use Cassandra because I know Cassandra very well, but if you're not great with Cassandra (or whatever), use what you know best.

For the use-case of Shopping cart (and checkout process) for E-commerce web application, what is better to use a Relational DB (RDBMS) or NoSQL DB as MongoDB/Cassandra/others ? 

For the catalog perspective, <code>NoSQL</code> makes ideal use-case with flexible schema, horizontal scaling of data/nodes.

What are the pros/cons of each approach for Shopping Cart use-case?

Ecommerce/Shopping Cart (and checkout process) : use Relational or NoSQL

数据库管理系统

关系型数据库

数据库管理

数据持久性

数据建模

数据分析

数据结构

SQL数据库

数据库

Cassandra

MongoDB

NoSQL

MySQL

对于电子商务web应用程序的购物车(和结账流程)的用例，使用关系型数据库管理系统( Relational DB，RDBMS)或NoSQL DB作为MongoDB/Cassandra/其他，哪个更好？对于目录透视图，NoSQL提供了灵活的模式、数据/节点的水平扩展的理想用例。购物车用例的每种方法的优缺点是什么？

问电子商务/购物车(和结帐流程)：使用关系或NoSQL
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问电子商务/购物车(和结帐流程)：使用关系或NoSQLEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问电子商务/购物车(和结帐流程)：使用关系或NoSQL
EN