解釋數據庫設計對我來說，和關係型與非關係型設計

Question

我天生前端的傢伙，但數據庫的設計和後端的開發已引起了我的興趣在過去的幾天裏，我纏綿很困惑。我想完全掌握這些概念，這樣我的頭就不會再受傷了。

我已經習慣了處理像活動記錄的ORM。當我通過導軌想象我的用戶對象時，我想象一個人的對象與people表中的一行有關。好的基本。

所以，我讀了像MongoDB的非關係數據庫不只是冷靜，因爲他們是「快大數據」，但他們也很酷，因爲他們顯然使開發更自然與OOP語言（爲什麼？ ）。然後我還讀到，大多數設計模式可能不是真正的關係。好的，這是我迷路的地方。

1）什麼是關聯設計和非關係型設計的一些基本的例子嗎？ 2）與上述類似，是什麼結構化數據VS非結構化（這只是上述改寫？）

因此，考慮到這些事情，我覺得（在我眼前的無知）幾乎所有類型的項目，我已經嘗試的例子模仿反對關係。但也許我只是在技術上使用語義。例如，帖子和評論。相互關係。在那裏添加用戶。似乎現在大多數應用程序都具有通過其他數據/對象始終有用的數據。這是關係，不是嗎？

如何描述不太典型的東西。

比方說，我正在構建一個鍛鍊跟蹤器應用程序。我有用戶，練習，鍛鍊，例程和log_entries。

我創建了一個例程來對鍛鍊進行分組。鍛鍊是一組練習。我通過日誌記錄記錄我的代表和體重，以便進行練習。這是關係數據還是非關係數據？ mongo會非常適合模擬這個還是非常糟糕的？

我聽到統計數據發揮作用。這是如何影響上述例子的？人們通常會說什麼統計數據？

比方說，我加入跟蹤別的東西，比如一個用戶的體重，身高，體胖等。這是如何影響事物的？

謝謝你花時間幫助我理解。

編輯：任何人都可以解釋爲什麼它可能會更容易開發一個比其他。正在使用像mongo這樣的更敏捷的東西，因爲一旦你「變成」它會「點擊」更多，也因爲你不需要運行遷移？

另一件事，使用類似的ORM的抽象的時候 - 它真的重要嗎？如果是這樣的話？對我來說，初始值將是查詢數據和建模我的對象的容易程度。無論什麼讓我更容易做到這一點，我會很高興。我嘗試模擬數據時，如實地發現自己會摸不着頭腦。

Answer 1

OK，讓我給它一個刺...

（免責聲明：我與非關係數據庫非常少的實際經驗，所以這將是一個有點「關係爲中心」）

關係數據庫使用「cookie-cutters」（表）生成大量統一的「cookie」（這些表中的行）。非關係型數據庫給你更大的自由度爲如何塑造你的「餅乾」，但你失去了設置基於SQL的力量。有點像靜態和動態類型。

1）關係設計和非關係設計的一些基本例子是什麼？

A tuple是屬性的有序列表，關係是一組具有相同「形狀」的元組，表格是關係的物理表示。如果某種東西符合這種範式，那就是「關係」。

金融交易往往是關係，而（說）文本文檔沒有。中間有很多灰色區域。

2）與上述類似，是什麼結構化數據VS非結構化（的例子是這樣的上述只是改寫？）

我不知道。你如何定義「結構化」？

似乎現在大多數應用程序都具有通過其他數據/對象始終有用的數據。這是關係，不是嗎？

當然。關係數據庫本身沒有「指針」，但外鍵實現的作用基本相同。可以隨時加入這些數據，您認爲合適的方式，儘管加入通常在FKS完成。

比方說，我是建設一個鍛鍊跟蹤器的應用程序。我有用戶，練習，鍛鍊，例程和log_entries。

它看起來像這樣很適合在關係模型中。

比方說，我添加了跟蹤其他東西，如用戶體重，身高，體脂等。這是如何影響事物的？

你可能需要額外的列和/或表。這仍然看起來與我有關係。

哪些統計人們通常講的？

也許他們正在談論index statistics，可幫助基於成本的查詢優化器選擇一個更好的執行計劃？

爲什麼它可能會更容易對其中任何作業的其他

合適的工具來開發，還記得嗎？如果您事先知道數據的結構並且它適合關係模型，請使用關係數據庫。另外，關係數據庫在管理大量數據方面往往非常好，許多用戶同時訪問（儘管對於一些非關係數據庫來說也是如此）。

另一件事，當使用像ORM這樣的抽象 - 它真的很重要嗎？

ORM傾向於使事情變得更容易，更難。再次，這是一個平衡的問題。對我而言，能夠編寫精確調整的SQL，精確地提取我需要的字段勝過編寫boiler-plate CRUD的繁瑣程序，所以我不是ORM的忠實粉絲。其他人可能會不同意。

我試圖模擬數據時，如實地發現自己搔抓了腦袋。

那麼，這是一個很大的話題。如果你願意付出時間和精力，可以從ERwin Methods Guide開始，也可以看看：Use The Index, Luke!