-1

Je suis un médecin junior et je crée un système de base de données pour mon médecin senior. Fondamentalement, mon Dr principal veut pouvoir stocker beaucoup d'informations sur chacun de ses patients dans une base de données relationnelle afin que plus tard, il puisse très facilement et rapidement analyser/vérifier les données (c.-à-d. En fonction de certaines données démographiques, trouver les traitements aboutissent à de meilleurs résultats ou quelles ethnies répondent mieux à certains traitements etc. etc.).Est-ce que j'ai trop de colonnes dans ma table MySQL?

L'information qu'il veut stocker pour chaque patient est énorme. Chaque patient doit effectuer 7 sondages (chacun ne prend que 1 à 2 minutes) un certain nombre de fois (immédiatement avant son opération, immédiatement après, 3 mois après, 6 mois après, 2 ans après et 5 ans après) - les scores finaux de Chacune de ces enquêtes à ces différents moments sera stockée dans la base de données.

En outre, il veut stocker leurs détails pertinents (nom, origine ethnique, sexe, âge, etc etc). Enfin, il a également l'intention de stocker BEAUCOUP d'antécédents médicaux pertinents, les symptômes actuels, les résultats de l'examen, les diverses options de traitement qu'ils essaient, puis les mesures des résultats.

Fondamentalement, il y a beaucoup d'informations pour chaque patient. Et toutes ces informations seront uniques à chaque patient. Donc, à cause de cela, j'ai créé une énorme table de patients avec (~ 400 colonnes) pour contenir toute cette information. La raison pour laquelle j'ai fait ceci est parce que la plupart des colonnes dans la table ne seront pas redondantes pour chaque patient.

De plus, tout ce système de base de données php/mysql ne sera disponible que localement sur son ordinateur, il ne sera jamais sur Internet. Les tables n'auront pas trop de patients, peut-être environ 200 à 300 d'ici la fin de l'année.

Compte tenu de tout cela, est-ce acceptable d'avoir une telle table énorme? Ou devrais-je diviser en plus petites tables à savoir - Les données démographiques - résultats de l'enquête - Symptômes - Traitements etc etc, avec un « patient_id » unique étant le lien entre chacune de ces tables?

Quelle serait la différence entre les deux approches et laquelle serait la meilleure? Pourquoi?

+0

Je ne ferais que des tables «patient» et «survey». 'survey' peut avoir un patient_id comme clé étrangère et un type d'enquête pour s'il était pré-op, post-op etc. Vous dites que les colonnes ne seront pas redondantes mais il y a deux problèmes ici. Vous créez des colonnes dans l'intention de les remplir 5 ans après l'insertion de la ligne, et vous n'êtes pas très flexible pour ajouter d'autres enquêtes à différents intervalles. – apokryfos

+1

@apokryfos et l'examen médical et les examens et leurs résultats. Il y a quelques tables que le PO devrait créer. – Shadow

+0

@Shadow oui, (je dois avoir manqué cette partie dans la première lecture de la question), une table 'past_history_entry' serait également nécessaire ayant un patient_id et les informations pertinentes à l'intérieur. Ce qui soulève la question de savoir comment cela pourrait être codé sous forme de colonnes dans un tableau, tous les patients n'auraient pas les mêmes entrées dans l'histoire que je ne pense pas. – apokryfos

Répondre

0

A propos des 400 colonnes ...

, le cas échéant, des colonnes seront importantes pour rechercher ou trier sur? Probablement très peu d'entre eux. Gardez ces quelques colonnes en colonnes.

Que ferez-vous du reste? Vous les affichez probablement quelque part, en utilisant du code d'application pour les imprimer correctement? Donc, ces peuvent également être dans une grande chaîne JSON.

Cela évite les cauchemars EAV, mais stocke les données dans la base de données dans un format qui est réellement raisonnablement facile (et rapide) à utiliser.