-1

Ich bin ein junger Arzt und ich erstelle ein Datenbanksystem für meinen Oberarzt. Grundsätzlich möchte mein Oberarzt viele Informationen zu jedem seiner Patienten in einer relationalen Datenbank speichern können, damit er später die Daten sehr einfach und schnell analysieren/auditieren kann (zB anhand bestimmter demografischer Daten, welche finden?) Behandlungen führen zu besseren Ergebnissen oder welche Ethnien reagieren besser auf bestimmte Behandlungen etc. etc.).Habe ich zu viele Spalten in meiner MySQL-Tabelle?

Die Informationen, die er für jeden Patienten speichern möchte, sind riesig.

Jede Patientin soll 7 Umfragen (jeweils nur 1-2 Minuten) mehrmals (unmittelbar vor ihrer Operation, sofort postop, 3 Monate postop, 6 Monate postop, 2years postop und 5 years postop) durchführen - die Endwerte von Jede dieser Vermessungen zu diesen verschiedenen Zeiten wird in der Datenbank gespeichert.

Zusätzlich möchte er ihre relevanten Details (Name, ethnische Zugehörigkeit, Geschlecht, Alter usw.) speichern.

Schließlich beabsichtigt er auch eine Vielzahl von relevanten Vergangenheit Anamnese, aktuelle Symptome, Untersuchungsergebnisse, die verschiedenen Behandlungsmöglichkeiten, die sie versuchen und dann Maßnahmen zu speichern.

Grundsätzlich gibt es eine Menge Informationen für jeden Patienten. Und all diese Informationen werden für jeden Patienten einzigartig sein. Aus diesem Grund habe ich eine riesige Patienten-Tabelle mit (~ 400 Spalten) erstellt, die all diese Informationen enthält. Der Grund dafür ist, dass die meisten Spalten in der Tabelle NICHT für jeden Patienten redundant sind.

Darüber hinaus wird dieses gesamte php/mysql-Datenbanksystem nur lokal auf seinem Computer leben, es wird nie im Internet sein.

Die Tabellen werden nicht zu viele Patienten haben, vielleicht gegen Ende des Jahres etwa 200 - 300.

Angesichts all dieser, ist es in Ordnung, eine so große Tabelle zu haben? Patientendaten - - Umfrageergebnisse - Symptome - Behandlungen usw. usw., mit einem einzigartigen „patient_id“ die Verbindung zwischen jeder dieser Tabellen ist Oder sollte ich es in kleinere Tabellen heißt werden Aufspaltung?

Was wäre der Unterschied zwischen den beiden Ansätzen und was wäre besser? Warum?

+0

Ich würde nur "Patienten" und "Umfrage" -Tabellen tun. 'survey' kann eine patient_id als Fremdschlüssel und eine Umfrageart für Pre-Op, Post-Op usw. haben. Sie sagen, dass die Spalten nicht redundant sind, aber es gibt hier zwei Probleme. Sie erstellen Spalten mit der Absicht, sie fünf Jahre nach dem Einfügen der Zeile zu füllen, und Sie sind nicht sehr flexibel beim Hinzufügen weiterer Umfragen in unterschiedlichen Intervallen. – apokryfos

+1

@apokryfos und medizinische histoy und Untersuchungen und ihre Ergebnisse. Es gibt einige Tabellen, die das OP erstellen sollte. – Shadow

+0

@Shadow ja, (ich muss diesen Teil beim ersten Lesen der Frage übersehen haben), eine Tabelle "past_history_entry" wäre ebenfalls erforderlich, die eine Patienten-ID und die relevanten Informationen enthält. Was die Frage aufwirft, wie dies jemals als Spalten in einer Tabelle codiert werden würde, würden nicht alle Patienten die gleichen historischen Einträge haben, die ich nicht denken würde. – apokryfos

Antwort

0

über die 400 Spalten ...

, die, wenn überhaupt, der Spalt wird wichtig sein, oder Art auf suchen? Wahrscheinlich sehr wenige von ihnen. Behalten Sie diese wenigen Spalten als Spalten bei.

Was machen Sie mit dem Rest? Wahrscheinlich zeigen Sie sie einfach irgendwo an und verwenden einen App-Code, um sie hübsch auszudrucken? So diese kann auch in einem großen JSON-String sein.

Dies vermeidet die EAV Alpträume, aber speichert die Daten in der Datenbank in einem Format, das eigentlich relativ einfach (und schnell) zu verwenden ist.

Verwandte Themen