RDBMS規範化與性能

我們正在編寫MMORPG並假設我們有以下表格。 location_dynamic_objects是要查詢和更新HEAVILY的表格。正如你可以看到position_x，position_y，location_id列以及對象類型重複。但是，如果我們規範化並使用連接，我們將爲選定的數據應用額外的過濾器。我們計劃將所有location_static_objects一次性發送給客戶，因此將它們與location_dynamic_objects保持在一起並沒有真正的意義。靜態對象表示要呈現的不可移動數據，並在位置加載時向客戶端發送一次。動態對象代表頻繁更新的數據，如玩家，火箭，小行星等，並不斷髮送給客戶端，取決於客戶的位置和位置。我們的問題是我們應該放棄規範化來實現績效？RDBMS規範化與性能

create table location_static_object_types (
    location_static_object_type_id integer auto_increment primary key, 
    object_type_name    varchar(16) not null 
); 
create table location_static_objects (
    location_static_object_id  integer auto_increment primary key, 
    location_static_object_type_id integer not null, 
    location_id     integer not null, 
    position_x      integer not null, 
    position_y      integer not null 
); 
create table location_dynamic_object_types (
    location_dynamic_object_type_id integer auto_increment primary key, 
    object_type_name    varchar(16) not null 
); 
create table location_dynamic_objects (
    location_dynamic_object_id  integer auto_increment primary key, 
    location_dynamic_object_type_id integer not null, 
    object_native_id    integer not null, 
    location_id      integer not null, 
    position_x      integer not null, 
    position_y      integer not null 
);

來源

2013-04-06 OneMoreVladimir

我不確定僅僅因爲可能會有一兩個連接，你的表現將被毀壞。通過適當的索引，調整，也許還有一些應用程序緩存，事情可能會像你需要的那樣快。 – mconlin 2013-04-06 23:27:44

只有在您經過全面測試並且有證據表明您需要恢復正常表單時，才應該進行標準化。 – Kermit 2013-04-06 23:30:27

即使我們添加索引，我們也需要過濾對象類型，重點是將未過濾的數據發送給客戶端。 – OneMoreVladimir 2013-04-06 23:39:58

由於非規格化會增加數據的冗餘度，因此會增加總數據量。出於這個原因，非規範化對於提高寫入訪問（創建和更新）數據的性能是非常罕見的;反之亦然。此外，即使對於讀取查詢，反規範化也會影響一小組查詢的性能提高，通常只有一組查詢會降低所有其他訪問非規範化數據的性能。如果你已經爲你的外鍵約束適當地使用了人造主鍵，並在你的自然鍵（主鍵）上補充了相應的唯一性約束，如果你通過非規範化看到了性能增益的好處，我會感到驚訝。

來源

2013-04-07 05:05:38

我確實同意你的觀點。但我不喜歡「恰當的標準化」涉及使用人造主鍵的含義。這兩件事沒有任何關係。 – 2013-04-07 10:41:08

我的關於人造主鍵的短語實際上是「正確使用」，這對性能有影響。 – 2013-04-07 11:51:38

RDBMS規範化與性能

回答

相關問題