1

私は複数の顧客が使用するためのアプリケーションを設計しています。最終的に、顧客レイアウトごとにスキーマを使用して単一のデータベースセットアップを作成しました。これは次のようになります。

CREATE TABLE public.companies
(
  id serial NOT NULL,
  name long_name NOT NULL,
  registration_number character(11),
  address character varying(256),
  CONSTRAINT "CompaniesPrimaryKey" PRIMARY KEY (id )
);

CREATE TABLE public.banks(.. );
CREATE TABLE public.calendars(.. );

-- Schema definition - none of the tables have company_id key
-- company_1 schema
CREATE TABLE company_1.employees
(
  id serial NOT NULL,
  first_name character varying(30),
  middle_name character varying(30),
  last_name character varying(50),
  bank_id integer,
  CONSTRAINT employees_pkey PRIMARY KEY (id )
);

CREATE TABLE company_1.contracts
(
  id serial NOT NULL,
  employee_id integer,
  calendar_id integer,
  CONSTRAINT contracts_pkey PRIMARY KEY (id )
)

-- company_2 schema same as schema company_1
-- and so on ...

すべての議論で、データベース設計についていくつかの議論があります。誰かがデータベース設計に何か問題があると言っていますが、誰も何を言うことができません。

本当に悪いことはありますか？この設計の本当の注意点は何ですか？

4

1 に答える 1

1

問題は、スキーマが変更された場合、アプリケーションが一貫した構造を見つけるようにすべてをアップグレードする必要があることです。アップグレード スクリプトは、それらすべてに対してアトミックである必要があります。

テーブルが同じデータベースにある場合は、アップグレード スクリプトをトランザクションでラップできるため、それほど悪くはありません。

一方、database-per-customer を使用し、RDBMS がトランザクションごとに複数のデータベースをサポートしていない場合、一部の顧客をアップグレードし、他の顧客を「クラッシュ」させる可能性があります。

また、必要に応じて、ある顧客を他の顧客から簡単に読み取らせることはできません (たとえば、すべての顧客のデータで満たされたオートコンプリート リストをすべての顧客に提供したい場合など)。

于 2013-01-27T11:46:06.203 に答える