我怎么知道我的数据本质上是关系型或面向对象的？

16

只需阅读这些行-

如果您的数据本质上是对象，则使用对象存储（“ NoSQL”）。它们将比关系数据库快得多。

如果您的数据本质上是关系型的，那么关系数据库的开销是值得的。

从-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

那么，我怎么知道我的数据是关系型的还是面向对象的呢？

object-oriented database relational-database

— 古尔山
source

告诉我们更多关于您的数据的信息

— FrustratedWithFormsDesigner

7

@FrustratedWithFormsDesigner我认为他正在寻找一般准则。

— C. Ross，

关于“键值存储的行”似乎描述了应在NoSQL中使用的“对象”数据-基本上，它可以使您以优雅的方式包含大量独立数据结构并以闪电般的速度访问它们听起来像是“自包含”的数据块，与其他数据块没有引用或关联……我无法给出很好的示例，因为这不是我习惯的（至少在这种情况下不是这样）。

— FrustratedWithFormsDesigner

刚刚获得此链接。希望它能提示答案-highscalability.com/blog/2011/6/15/…–

— Gulshan

16

冒着被炸成碎片的风险，我将尝试使用简单的英语定义。

对我来说，“关系性质”的含义是：特定类型的所有项目都具有几乎相同的属性，这使得设计一个简单的表变得非常容易，但是将所有项目都放入该表中，然后再通过SQL执行CRUD和检索。另外，如果可以对数据进行建模以使所有项目都具有一组有限的类型之一，则可以定义与该组类型相对应的关系数据结构。

“对象性质”翻译为：相似类型的项目可以具有多种属性，并且这些属性在性质和类型上可以具有多种多样。通常，可以（经过足够的努力）将其转换为关系模型，但是很多表的填充非常稀疏，最终导致效率低下的LEFT OUTER联接，这使得关系数据库的性能与之相比显得缓慢到NOSQL数据库。

我不得不说，从我的角度来看，没有严格的界限将这两者分开。您可能会发现许多介于两个极端之间的示例。

好的，所以现在我向各个方向的狙击手敞开大门。欢迎任何意见。让我们看看是否可以一起改进此定义。

— 沃尔夫冈斯
source

1

实际上，作为最初对这个问题的简单性不屑一顾的人，我不得不说“勇敢”才能得到一个可以理解和有见地的答案。您应该研究写书。

— 菲利普（Philip）

我们是否可以将其概括为“在关系设计中有太多的外部连接”？

— Gulshan

我会犹豫进行这样的简化。这是症状之一，但不是唯一的症状。

— wolfgangsz

请举个例子吗？

— Gulshan

假设您存储有关人员的信息。任何人都可以具有一组300个属性的任意组合。所有这些属性可以出现多次，或者根本不出现。其中一些由其他属性组合组成，即它们是集合。现在，您要搜索不存在特定属性或没有特定属性的所有人员。那样的事情会使普通的SQL查询构建器发疯。

— wolfgangsz

5

数据都是两者。

（严格来说，它本质上不能成为对象，因为它缺乏行为，但我们不会挑剔）。

在RDBMS或NoSQL数据库中存储数据的决定更多地取决于您打算如何使用数据，而不是数据本身的真正“性质”。

如果您打算支持数据的所有导航路径，那么您可能希望将数据存储在RDBMS中，因为您将使用不同的方式来访问和显示数据。您需要数据库为您做很多繁重的工作。例如，可以通过客户，销售人员，sku（项目），日期，地区等访问“订单”数据。

另一方面，如果您的导航路径最少，则可以只存储整个对象。例如，仅可由Web前端访问并且不能长期存储或分析过多的“篮子”可能更适合于NoSQL存储。使用（文档或键值）NoSQL数据存储所做出的牺牲是，在没有集合之间的关系的情况下-如果不需要这些关系（用于导航路径，即席查询或报告），并在您的数据库中加以照顾应用程序，那么您会没事的。

当然，您可以出于两种原因同时存储数据，但这有其自身的缺点。

— 西蒙·蒙罗
source

2

数据不是“本质上的对象”或“本质上的关系”。任何类型的数据都可以用关系模型或对象模型/图形结构表示。合适的方法取决于应用程序将如何使用数据。通常，您甚至可能同时拥有两者。例如，网站上使用的数据可以存储在关系数据库中，但是按需加载到图形结构中，然后将其缓存在内存中的键值存储中。

对于某些类型的数据，对象存储/ NoSql的语句将比关系语句快。同样重要的是您的应用程序如何使用数据，而不是数据本身的形式。对象存储在加载作为一个单元存储的对象图时会更快，但是在跨多个对象进行临时查询或更新许多对象的属性时会慢很多。

— 雅克B
source

0

我认为这篇文章的重点是：

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

在我看来，作者提出了一个很好的观点，即如果您的代码例如出于某种逻辑考虑而获得了“西班牙的客户数量”，那么您不应在西班牙的所有客户中填充客户列表，然后再进行计数客户对象。（ORM可能会推动您这样做）

显然，您无法从客户数据结构本身中得知是否会那样使用它。因此，我认为我们应该将“数据”解释为“您的应用程序使用的所有信息”。如果这包括聚合或“与Y相关的所有X”之类的内容，则您的“数据”不适合原子NoSql方法

— 伊万
source