オブジェクト指向のデータをリレーショナルデータベースの単一の行に直接エンコードするのは悪い方法ですか？

Question

私はデータベースには比較的新しいので、これにアプローチする明白な方法がある場合、または欠落している基本的なプロセスがある場合はお詫びします。私は患者の医療記録を含むWebアプリケーションでPHPとMySQLを使用しています。 1つの要件は、ユーザがウェブページから医療記録を閲覧および編集できることである。

私はそれを想定したように、単一Patientオブジェクトはid、name、及びaddressなどの基本的な属性を有し、各PatientもMedicationオブジェクト（med_name, dose, reason）、Conditionオブジェクト（cond_name, date, notes）、および他のそのようなオブジェクト（の配列を有しますアレルギー、家族歴など）。

• 患者（ID、名前、住所、...）
• 薬（patient_id、med_name、用量、理由）
• ：次のように私が最初に考えたのはテーブルとデータベースのスキーマを持っていることでした条件（patient_id、cond_name、日付、メモ）
• ...

はしかし、これは私には間違っているようです。新しい薬や条件を追加するのは簡単ですが、既存の薬や条件を削除したり編集したりするのは非常に効率が悪いと思われます。テーブルでpatient_idと一致する行を探して、古いmed_name、dose、reasonフィールド、新しいデータで削除/編集します。 medicationsとconditionsテーブルにいくつかの主キーを追加して、編集する行をより効率的に見つけることができますが、これは任意のデータのように見えます。

したがって、次のスキーマを持つ単一のテーブルがあった場合はどうなりますか？

• 患者（ID、名前、住所、クスリ、conds、...）medsとcondsは、単にMedicationとConditionオブジェクトの配列の表現（たとえば、バイナリ）です

？ PHPはこのデータを解釈し、必要に応じてデータベース内のデータを取得して更新することができます。

ここでのベストプラクティスについてのご意見は歓迎します。私はRuby on Railsに切り替えることも考えています。もしそれが何らかの決定に影響を与えるならば、それを聞くことに興味があります。ありがとうたくさんの人。

Answer 1

あなたのニーズに応じて、あなたのデータをエンコードすることの「悪さ」や「良さ」は、 NEVERが、「meds」および「conds」テーブルの個々の小さなチャンクを参照する必要がある場合、問題はありません。

しかし、あなたは本質的にあなたのデータベースをやや賢いストレージシステムに減らし、SQLデータベースの「リレーショナル」な部分の利点を失います。

「バイアグラを取って心臓病を患っているすべての患者を見つける」ためにクエリを実行する必要がある場合、DBMSはそのクエリを直接実行することはできません。どのようにしてバイアグラを隠したかはわかりません/心臓状態のデータを含むことができますが、正常に正規化されたデータベースでは、次のようになります。

SELECT ... 
FROM patients 
LEFT JOIN conditions ON patients.id = conditions.patient_id 
LEFT JOIN meds ON patients.id = meds.patient_id 
WHERE (meds.name = 'Viagra') AND (condition.name = 'Heart Disease') 

DBMSは自動的にすべてを処理します。すべてを1つのフィールドにエンコードしている場合、部分文字列操作（データが読みやすいASCII形式であることを前提としています）が悪い場合や、データベース全体をクライアントアプリケーションに吸い込ませて各フィールドをデコードする必要がある場合、その内容を確認し、バイアグラや心臓病を含まないすべてのものを捨てる - 非常に非効率的です。

Answer 2

これは最初の正規形を破ります。そのようにオブジェクトの属性を照会することは決してできません。

オブジェクトがある場合はORMソリューションを、オブジェクトデータベースを使用することをお勧めします。

Answer 3

私は、たとえば、古いmed_name、投与量、および理由フィールド、 で行 一致patient_idのための薬のテーブルを検索して、新しいデータで編集し、それを/削除する必要があると思います。キーは{patient_id、med_name、START_DATE}だったと仮定すると、

は、あなただけの単一の更新を行うと思います。検索しません。ユーザーが何らかの形で変更が意味をなすだろう前にそれらがしている行を「選択」する必要がありますので

update medications 
set reason = 'Your newly edited reason, for example.' 
where patient_id = ? 
    and med_name = ? 
    and start_date = ? 

アプリはすでに、患者ID、medの名前を知っている、と日付を起動します。

投与量を変更する場合は、意味を理解するために、更新と挿入の2つの変更が必要です。

このため

update medications 
set stop_date = '2012-01-12' 
where patient_id = ? 
    and med_name = ? 
    and start_date = ? 

-- I'm using fake data in this one. 
insert into medications (patient_id, med_name, start_date, stop_date, dosage) 
values (1, 'that same med', '2012-01-12', '2012-01-22', '40mg bid')