針對每種類型的CSV文件創建運行時數據庫表格

Question

以下是完整的詳細信息。

Web應用程序從CSV文件創建報告 有不同格式的CSV文件 用戶將能夠添加新格式或將能夠添加新的字段。

我的客戶希望我爲每種類型的CSV文件創建表...所以對於每種新格式都會有一個新表... 我相信這是一個糟糕的設計決定。但不知道如何向我的客戶解釋這一點。

這裏是我能想到的，現在的原因：

1. 這是一個不好的設計決策
2. 一年以後會有像> 10000臺，系統將變得不穩定
3. 實施將是耗時
4. 維護將是困難的
5. 數據會得到不可收拾，最終
6. 無法輕鬆遷移到其他服務器

我的理由有效嗎？你怎麼看？你能告訴我一些這方面的情況嗎？

非常感謝您的幫助

Answer 1

如果你只是從CSV文件創建報告，所以爲它創建表。您可以直接存儲CSV並創建報告...

BTW這是一個糟糕的設計決策，因爲......「這是一個糟糕的設計決策」，是業務用戶不信任的一個很好的例子程序員。

Answer 2

您提供底片。我認爲如果你另外提供好的解決方案，你有更多的機會。

新格式多久出現一次？可能是一個表的動態變化（如你所說，它可能只是列添加）是決定？

Answer 3

以你的觀點：

1. 雖然如此，你將需要爲什麼來支持這一行動。
2. 不穩定？取決於您正在使用的DBMS。
3. 不一定。創建和刪除表是一項相對簡單的任務。
4. 同樣，不一定。這些表格應完全由應用程序管理..這意味着很少或沒有直接維護
5. 不知道你如何確定這一點。
6. 移動到服務器應該像備份和恢復數據庫到另一臺機器一樣簡單。假設你不能這樣做，那麼有很多工具可以爲你做到這一點。

---

這就是說，爲什麼我不會做這種情況的原因是：

1. 安全。爲了允許應用管理表格，您必須授予用戶創建/刪除它們的權限。這爲黑客打開了數據庫的可能性。 （POET任何人？）
2. 安全。你幾乎可以保證你將使用動態sql來完成這個常規的DBMSs，這意味着你必須知道SQL注入的可能性。
3. 安全。我有沒有提到應用用戶基本上需要對數據庫擁有完全的權利？

---

至少有兩個備選方案。一種是使用像MongoDB這樣的NoSql數據庫。它可以在您很少的指導下即時創建和更改表格。這種相對非結構化的數據正是這些數據庫系統的用途。您可能會考慮將上傳到MongoDB或類似的應用程序，而其他應用程序使用傳統的RDBM。

第二個是使用支持虛擬表格的表格設計。這意味着您有一個主表，其中包含表名，另一個表包含字段，最後一個表保存名稱/值對關聯中的數據。這條道路並不值得懷疑，因爲報告可能是一個問題，但會跳過所有的安全問題。

Answer 4

不要混淆客戶希望程序做什麼，以及如何實際實現它。

他們希望你的程序讀取CSV文件並報告它們，就是這樣。這取決於你和你的技術技能，這個客戶應該在你如何實現這個方面說出ZERO。內部表格和應用程序設計不適合最終用戶指定。

這個人會告訴醫生如何切入他的主動脈？

Answer 5

在這裏服務的實際要求是什麼？來自那裏的數據在哪裏填充CSV文件？爲什麼你需要這些數據的另一個副本？

數據似乎很可能無法以您描述的形式使用。但是由於你沒有說出你實際想要達到的目標，所以很難更具體。

Answer 6

您錯過了問題呈現中的一條重要信息：您收集的CSV文件代表了哪些信息？作爲一般原則，如果CSV文件是呈現相同類型信息的簡單不同方式（也就是說，有些人向您發送更多或更少關於相同「事物」的詳細信息字段），那麼，如果您在關係數據庫中收集這些信息，我想說你一定要有一個公共表（或者一組通用表來正確表示數據）。對於可能需要轉換爲「事物」的每種CSV格式的文件，您都將擁有一個單獨的導入程序，但無論「事物」來自哪種CSV文件，存儲都是相同的。另一方面，如果每個CSV文件代表不同的「事物」，並且您確實在構建某種通用CSV報告工具，那麼我懷疑關係數據庫是否是正確的存儲機制項目，儘管我想在做出任何類型的陳述之前知道更多關於你實際上做了什麼的細節。