在SQL中存儲數千個數字的最佳方法是什麼？

我有大約250種產品，他們都有52周的歷史+ 52周的預測。我需要在SQL中存儲這些數字，但無法找出最佳的方式。我只使用過幾次數據庫，所以我的知識非常有限......在SQL中存儲數千個數字的最佳方法是什麼？

我想過使用純文本和讀/寫分隔符。但是在很多方面它感覺不好，並且使整個數據庫變得毫無用處。

然後我想到在桌子上增加52列，但我看到這是一個壞主意。

所以現在我回到我開始和它只是一個帶有

[ID] [WEEK_NUMBERS] [HISTORY_NUMBERS] [FORECAST_NUMBERS]

這是做的最好的方式表？

〜25000-30000行不是問題？

來源

2017-04-02 Kenneth Knutter

25000-30000行完全沒有問題。你走在正確的道路上！ –

低於100萬的任何行數都是小數據庫。 Storagewise你根本沒有問題。 –

你會使用一個表是這樣的：

create table ProductHistory (
    ProductHistoryId int identity primary key, 
    ProductId int not null references Products(ProductId), 
    Type varchar(255) not null, 
    Week date not null, -- storing this as a date is a guess 
    Number decimal(38, 10), -- should probably be decimal, but the scale and precision might be overkill, 
    constraint chk_ProductHistory_type (type in ('Forecast', 'Actual') 
);

這是一個例子。目前尚不清楚：

是否每一行都有一列用於預測和實際值，還是應該在不同的行上？
week應如何儲存？
什麼是Number的正確類型？

但是這個想法是一樣的。。。每個產品/周至少組合一行。

來源

2017-04-02 15:09:16

或者，你可以按照行業標準，並命名主鍵'ID' – Bohemian

@波希米亞。。。我*不會考慮「行業標準」。如果你有不同的想法，你可以調查'USING'子句的用途和用法。 –

我從不使用''使用'，因爲它不便攜式，它需要更多的字符才能輸入（是的，它！），並且不會帶來任何性能優勢。在壞主意列表中用'自然連接'就在那兒。思考*超越* SQL，如果使用類似JPA的框架連接數據庫，如果以不同的方式命名每個ID列，則最終會得到敷衍的代碼，以迎合來自OO角度的字段命名變化* *與*相同*行爲的字段（自動增量等）。這是糟糕的設計。在任何地方命名它意味着更少的代碼，所有表的一個基類，等等。 – Bohemian

在SQL中存儲數千個數字的最佳方法是什麼？

回答

相關問題