Conception de base de données SQL Server pour les données de prix du marché boursier à haut volume

Question

J'écris l'application pour stocker et récupérer les données de prix du marché boursier que les données sont insérées quotidiennement. Je stocke les données pour chaque actif (Stock) et pour la plupart du marché dans le monde. Ceci est ma conception actuelle des tables

Pays Table:

CREATE TABLE [dbo].[List_Country] 
(
    [CountryId] [char](2) NOT NULL, 
    [Name] [nvarchar](100) NOT NULL, 
    [CurrenyCode] [nvarchar](5) NULL, 
    [CurrencyName] [nvarchar](50) NULL 

    CONSTRAINT [PK_dbo.List_Country] 
     PRIMARY KEY CLUSTERED ([CountryId] ASC) 
) 

Asset Tableau:

CREATE TABLE [dbo].[List_Asset] 
(
    [AssetId] [int] IDENTITY(1,1) NOT NULL, 
    [Name] [nvarchar](max) NOT NULL, 
    [CountryId] [char](2) NOT NULL, 

    CONSTRAINT [PK_dbo.List_Asset] 
     PRIMARY KEY CLUSTERED ([AssetId] ASC) 
) 

contrainte de clé étrangère sur Pays:

ALTER TABLE [dbo].[List_Asset] WITH CHECK 
ADD CONSTRAINT [FK_dbo.List_Asset_dbo.List_Country_CountryId] 
    FOREIGN KEY([CountryId]) 
    REFERENCES [dbo].[List_Country] ([CountryId]) 
     ON DELETE CASCADE 
GO 

STOCK_PRICE table:

CREATE TABLE [dbo].[Stock_Price_Data] 
(
    [StockPriceDataId] [int] IDENTITY(1,1) NOT NULL, 
    [AssetId] [int] NOT NULL, 
    [PriceDate] [datetime] NOT NULL, 
    [Open] [int] NOT NULL, 
    [High] [int] NOT NULL, 
    [Low] [int] NOT NULL, 
    [Close] [int] NOT NULL, 
    [Volume] [int] NOT NULL, 

    CONSTRAINT [PK_dbo.Stock_Price_Data] 
     PRIMARY KEY CLUSTERED ([StockPriceDataId] ASC) 
) 

contrainte de clé étrangère sur Asset:

ALTER TABLE [dbo].[Stock_Price_Data] WITH CHECK 
ADD CONSTRAINT [FK_dbo.Stock_Price_Data_dbo.List_Asset_AssetId] 
    FOREIGN KEY([AssetId]) 
    REFERENCES [dbo].[List_Asset] ([AssetId]) 
     ON DELETE CASCADE 

Ce qui me préoccupe à l'heure actuelle est la table Stock_Price_Data serait rempli de lignes à haut volume, par exemple pour un marché spécifique dans un pays, il peut y avoir facilement 20 000 actifs. Ainsi, en un an (260 jours de trading), je pourrais potentiellement avoir 5,2 millions de lignes pour chaque pays.

L'application n'empêche pas un utilisateur d'accéder à des données autres que le pays par défaut (qui est configuré lors de la connexion).

Est-ce une bonne idée d'avoir une table séparée (par exemple Stock_Price_Data_AU) pour chaque pays? Ou y a-t-il une meilleure façon de concevoir la base de données pour le scénario ci-dessus?

-Alan-

Answer 1

tout d'abord - je laisse tomber la _data du nom de la table - son surpuissant. Si vous êtes raisonnablement certain que les utilisateurs filtreront toujours les données par pays, c'est-à-dire en ne regardant qu'un pays à la fois, je considérerais le partitionnement par ID de pays - de cette façon, SQL Server utilisera l'élimination des partitions pour donnée pertinente. De cette façon vous obtenez la facilité d'entretien de 1 table mais vous obtenez la performance comme si c'était une table séparée par pays. (Je suppose que vous avez Enterprise Edition) Si votre charge fonctionne sur une base par pays aussi, vous pouvez même désactiver la partition, puis laisser tomber les index pour obtenir des charges encore plus rapides.