Performance des colonnes supplémentaires par rapport aux lignes supplémentaires

Question

J'ai une question sur la conception et la performance des tables. J'ai un certain nombre de machines analytiques qui produisent des quantités variables de données (qui ont été stockées dans des fichiers texte jusqu'à présent via les programmes DOS qui exécutent les machines). J'ai décidé de moderniser et de créer une nouvelle base de données pour stocker tous les résultats de la machine.

J'ai créé des tables séparées pour stocker les résultats par type par ex. tous les résultats de la machine d'équilibrage sont stockés dans les résultats de la balance tableau, etc.

J'ai un format de tableau commun de résultats pour chaque machine qui est la suivante:

ClientRequestID PK 
SampleNumber  PK 
MeasureDtTm 
Operator 
AnalyteName 
UnitOfMeasure 
Value 

Un ClientRequest typique pourrait avoir 50 échantillons qui ont besoin testé par différentes machines. Chaque machine enregistre seulement 1 ligne par échantillon, donc il y a environ 50 lignes par table associées à une demande client donnée.

Ceci est bien pour toutes les machines sauf une!

Il mesure 20-30 analytes par échantillon (et les recrache simplement dans une longue rangée), tandis que toutes les autres machines, je mesure seulement 1 analyte par RequestID/SampleNumber. Si je m'en tiens à ce format, cette machine générera plus d'une miliion de lignes par an, car chaque échantillon peut avoir jusqu'à 30 mesures. Mes autres tables ne se développeront qu'à raison de 3000 à 5000 lignes par an.

Ainsi, après tout cela, ma question est la suivante:

Suis-je mieux coller au format commun pour cette table, et ont des charges seau de lignes, ou est-il préférable d'ajouter simplement des colonnes supplémentaires pour représenter chaque Analyte, de sorte qu'il ne générerait qu'une seule ligne par échantillon (comme les autres tables). La machine ne peut mesurer qu'un maximum de 30 analytes (et 250k $ par machine, je n'en gagnerai pas une de ma vie).

Tout ce qui m'inquiète, c'est de rapporter les performances et l'édition en ligne. Dans les deux cas, le PK: RequestID et SampleNumber restent les mêmes, donc je suppose que c'est juste une question de ce qui chargerait plus rapidement. Je sais que l'approche par colonnes multiples est considérée comme déplorable du point de vue de la conception, mais serait-elle plus performante dans ce cas?

BTW la base de données est MS Jet/Access 2010

Toute aide serait grandement appréciée!

Answer 1

Vous pouvez découpler la colonne AnalyteName de la table « résultats communs »:

-- Table Common Results 

ClientRequestID PK SampleNumber PK MeasureDtTm Operator UnitOfMeasure Value 

-- Table Results Analyte 

ClientRequestID PK SampleNumber PK AnalyteName 

Vous rejoindre sur le PK (demande + échantillon). De cette façon, vous ne dupliquez pas tout le reste des lignes inutilement , peut éviter la jointure dans les requêtes où vous n'avez pas besoin de l'AnalyteName à utiliser, peut supporter des Analytes supplémentaires et est globalement plus sain. À moins que vous ne commenciez vraiment à avoir un problème de performance, c'est l'approche que je suivrais.

Heck, même si vous commencez à avoir des problèmes de performance, je voudrais tout d'abord passer à une véritable base de données pour voir si cela résout les problèmes avant d'ajouter des colonnes au tableau des résultats.

Answer 2

Des millions de lignes dans une base de données Jet/ACE ne sont pas un problème si les lignes ont quelques colonnes.

Cependant, ma préoccupation est de savoir comment ces documents sont insérés - est cette collecte de données en temps réel?Si oui, je dirais que c'est probablement plus que Jet/ACE peut gérer de manière fiable. Je suis un développeur expérimenté d'Access qui est un grand fan de Jet/ACE, mais d'après ce que je sais de votre projet, si je commençais, je choisirais certainement une base de données de serveur dès le départ, pas parce que Jet/ACE ne peut probablement pas le faire en ce moment, mais parce que je pense en termes de 10 ans plus tard quand cette application pourrait encore être utilisée (rappelez-vous Y2K, qui était principalement un problème d'applications qui ont été conçues avec obsolescence planifiée à l'esprit, mais n'ont jamais été remplacés).