1

我曾经使用过这样的 MySQL 和数据库设计。

医院 rdbms 设计

该数据库是为医院设计的。在患者表中有超过 1.500.000 条患者记录。在临床表中有 15 条记录。在医生表中有 25 条记录。在诊断表中有超过 500 条记录。在 out_condition 表中有 10 条记录。

并且所有要在表 transaction_current 中关联的表。完成后，事务移至历史表。

这是一个糟糕的设计吗？因为在查询选择中，需要一分钟以上才能让一名患者处于浏览模式。如果这是最好的关系设计，我应该如何使用包含所有关系表引用的事务表的选择查询。

谢谢你的帮助。

编辑：“对不起......我的形象设计在哪里？只有我的borwser吗？......”

这是示例选择查询

select  transaction_current.registration_number, 
        transaction_current.Date_registration, 
        patient.mr_code, 
        patient.patient_name,
        clinic.Poly_clinic_name, 
        doctor.doctor_name, 
        diagnose.diagnose_name,
        out_condition.OC_name
from transaction_current,patient, clinic, doctor, diagnose, out_condition
where   transaction_current.patient_code=patient.MR_code and 
        transaction_current.clinic_code=clinic.clinic_code and 
        transaction_current.doctor_code=doctor.doctor_code and 
        transaction_current.diagnose_code=diagnose.doagnose_code and 
        transaction_current.OC_code=Out_Condition.OC_code
        and patient.patient_name = 'xxx%'

回答：经过先生的仔细回答。rj45，有时不建议进行任何规范化。尤其是历史数据。如果参考表发生变化，历史数据也会发生变化。像这样的情况……如果代码更改医生，或删除，那么记录将跟随更改历史。当它不在遗嘱中时。其极端，数据历史不会出来，因为关系代码不匹配。非常感谢@rj45

4

2 回答 2

0

最好对查询应用一些优化步骤。

例如： - 在查询中适当地使用运算符 EXISTS、IN 和表连接

最好避免在 where 子句中进行过多的比较。我相信这是你有滞后的地方。您可以比较具有构建索引的字段。所以它会在查询上快得多。

PS：尽管有时存在标准化，但最好坚持使用较少标准化的形式（根据经验；））

于 2012-09-03T05:15:00.080 回答
0

你的桌子设计看起来不错。它已标准化，我不认为设计会出现任何性能问题。作为使用的引擎（InnoDB？）的更多细节，特定表的定义和现有索引将帮助其他人提供更多建议。

您的查询似乎加入了 4 个相当小的表和两个较大的表（patient和transaction_current）。因此，如果您已经定义了图像显示的外键并且它们被索引（以及相同数据类型的引用和引用列），则此查询应该非常快。

最可能的瓶颈是patient_name. 这将需要对表进行表扫描patient。

于 2012-09-03T08:11:14.093 回答