0

私は複数の種類のフォームがある大学で働いています。レポート、速度、メールボックスの制限など、さまざまな理由から、古いシステム（フォームデータ->電子メール）をより効率的なシステム（SQL）に変換しています。

私は正規化とSQLコマンドをうまく理解しています...私はこれらにこだわっています：

  1. 必須フィールドとオプションフィールド（nullまたは個別のテーブル）
  2. フォームの変更（フィールドの追加/削除、およびテーブルデザインへの反映方法）
  3. 1：1のフォームとテーブルの比率または1：Nのフォームとテーブルの比率
  4. 1：Nの場合、これは各フォームのレポートに影響しますか？

私の懸念に触れるデータベースにフォームデータを保存する方法に関する優れた情報を提供するサイト/本/記事/チュートリアルを知っていますか？

または、「試行錯誤した」方法とは何か説明していただけますか？

できれば3回目か4回目の正規化を目指したいです。

私の最初の考えは次のとおりです。

  1. 必要なすべての（永続的な）データのフィールドを持つテーブル「アプリケーション」を作成します。
  2. 次のフィールドを持つテーブル「application_extra」を作成します：application_id、field_title、field_value

しかし、これは報告しても大丈夫でしょうか？

ありがとう！

4

1 に答える 1

0

静的フォームを扱っている場合、フォーム/テーブルが変更されるという実際のリスクはありません。変更されたとしても、テーブルの列をすばやく変更し、PHP送信コード（つまりクエリ）を少し変更する必要があります。 、 以上です。

動的フォームは少し異なります（動的フォームは、ユーザー入力またはサーバー条件のいずれかによってサーバーによって生成されたフォームです）。フォームごとに2つのテーブルが必要です。1つはフォームの構造用で、もう1つはフォームに保存されたデータ用で、結果は多対1の関係で保存されます。

構造talbeの例：

CREATE TABLE IF NOT EXISTS `form_structure` (
  `id` int(10) unsigned NOT NULL,
  `name` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'Name of the form element as appeared on its name attribute',
  `type` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'text' COMMENT 'Type of the form element (text, password, checkbox etc).',
  `label` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'Label for the form element.',
  `can_be_null` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Whether the form element can be null.',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
于 2012-07-14T06:42:52.197 に答える