我永遠無法決定在將數據插入數據庫或將其拉出之前更好地格式化數據。在插入數據庫之前或之後格式化數據？
我不是在談論數據消毒;我們都知道要防範SQL注入。我說的是，如果用戶給你一個URL，並且它沒有http：//在它之前，你應該在將它插入數據庫之前添加它還是將它拉出來？更復雜的事情呢，比如格式化一大堆文字。我想在之前還是之後用HTML標記它（或將其去掉）？如果我稍後改變主意並想要以不同的方式進行格式化，該怎麼辦如果我已經格式化了它，我無法做到這一點，但如果我將它存儲爲未格式化的，我可以做到這一點......但是，我每次從數據庫中提取一段數據時都會做額外的工作，完成一次並完成它。
你的想法是什麼？
從答案，似乎有一個普遍的共識是東西像URL，電話號碼和電子郵件（有一個明確定義的格式的任何東西），應先標準化，以統一的格式。像文本這樣的東西通常應該保持原始或以可操作的格式來實現最大的靈活性。如果速度有問題，則可以存儲這兩種格式。
在插入之前將URL規範化爲規範形式可能是可以的;執行任何種類的廣泛格式化，例如HTML轉換/解析等我覺得這是一個糟糕的主意 - 在你的數據庫中總是要有「最」可能的數據，特別是如果你想稍後改變表示格式。
爲避免對每個查詢進行不必要的後處理，您可以考慮採用對象緩存或類似的技術來處理更昂貴的操作。
我認爲最好確保數據庫中的數據採用最一致的格式。您可能有多個應用程序使用此數據，因此如果您可以確保它們的格式完全相同，則不必擔心在每個應用程序中重新格式化不同的格式。
在我看來，它應該先格式化。如果您選擇在檢索而不是插入時執行此操作，則當其他應用程序/腳本想要使用同一數據庫中的數據時，這可能會導致問題出現。他們都需要知道如何清理數據時，他們拉出來。
取決於
如果你做得很好定義的項目，SSN，郵政編碼，電話號碼，其存儲格式（這並不一定意味着包括虛線或點，等它可能意味着刪除它們如此everyhting是是一致的。
你必須非常小心，如果您在保存之前更改的數據。你總是可以運行在你需要呼應回原來的用戶，他們給你的確切文本的情況。
你在這裏問兩個問題
標準化應始終在數據庫插入之前執行，例如，如果一列只有URL，那麼他們應該首先被標準化。
關於格式化，這是一個觀點的問題，而不是一個模型（在這種情況下，DB）的問題。
我的傾向通常是以最靈活的形式存儲數據。例如，數字應該使用整數或浮點類型來存儲，而不是字符串，因爲您可以使用數字類型進行數學運算，但不能與字符串進行數學運算（儘管將數字解析爲字符串很容易，但這並不是什麼大問題） 。也許一個更實際的例子：應該使用數據庫的實際日期/時間數據類型而不是字符串來存儲日期/時間。另外，也許將HTML轉換爲純文本比反過來更容易，在這種情況下，您希望將文本存儲爲HTML。或者甚至可以使用像Markdown這樣的格式，它可以很容易地轉換成HTML或純文本格式。
存在矢量圖形格式（SVG，EPS等）的原因是相同的：SVG文件本質上是指定如何繪製圖像的一系列指令。將其轉換爲任意大小的位圖圖像很容易，而如果您只有一個位圖圖像，那麼在改變其大小（例如創建縮略圖）的同時又不會損失質量，就很難了。
您可能想要存儲格式化和未格式化的數據版本。例如，我們以美國電話號碼爲例。如果您只存儲一列，並且只存儲最常用格式的數字和一列，例如（111）111-1111，那麼您可以輕鬆地格式化爲特殊情況的客戶端規格，或者快速將最常見的格式拉出，而無需大量鑄造。這在插入時只需要很少的額外時間（並且可以通過計算列來完成，因此無論數據來自哪裏都會發生）。
數據在放入數據庫之前應該進行清理，以避免無效日期或非數值數據等被放置在字段中。電子郵件是人們經常因爲某種原因放入垃圾的一個領域。如果它沒有@符號，則不應該存儲。如果您確實使用該字段向您的應用程序發送電子郵件，則情況尤其如此。如果你明白我的意思，試着發郵件給'聯繫他的祕書'或'aol.com'是浪費時間。
如果格式將一直需要，最好在插入或更新時將數據轉換爲該格式，而不必再次將其轉換。如果標準格式發生變化，那麼您需要更新當時所有現有記錄的列，然後使用新格式。如果您經常更改格式和大表格，或者如果不同的應用程序使用不同的格式，則最好存儲未格式化的格式。
+1：數據庫必須絕對一致。 – 2009-04-08 21:00:13
+1：對於剛剛計劃在其他地方檢索和重用的數據很重要，而對於可能使其成爲WHERE子句的數據，CRITICAL很重要。 – ojrac 2009-04-08 21:56:58