Дизайн базы данных для поддержки нескольких клиентов

Question

Если вы строили базу данных со столами Документы, клиенты, пользователи и фирмы, где в Фирмах вы могли бы хранить компании, которые используют программное обеспечение, как бы вы создали первые три таблицы для поддержки нескольких Фирм хранить в них? Итак, в документах мы хотим хранить документы для всех фирм, конечно, нам нужно как-то сказать им appart, поэтому нам понадобится столбец, такой как FirmID. Мы также можем поместить это в Клиенты и Пользователи.

Теперь следующее требованием является то, что каждая фирма может иметь свои собственные идентификаторы для документов, клиентов, потому что obviosuly при добавлении новой фирмы, их идентификаторы для то, что они создают должны начать с 1.

я что-то думать как это, но для этого требуется ручное построение всех полей, но RowID.

CREATE TABLE [dbo].[ClientTest](
[RowID] [int] IDENTITY(1,1) NOT NULL, 
[FirmID] [int] NOT NULL, 
[ClientFirmID] [int] NOT NULL, 
[ClientFirmPrettyID] [varchar](10) NOT NULL, 
CONSTRAINT [PK_ClientTest] PRIMARY KEY CLUSTERED 
(
[RowID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 

RowID будет работать автоматически в этом случае, но это бесполезно для нас, потому что за все, что мы делаем, мы должны использовать ClientFirmID и ClientFirmPrettyID. Есть ли способ автоматизировать создание этих двух?

Answer 1

Это хорошая практика использования шаблона фасада базы данных (представления, хранимые процедуры), которые скрывают всю внутреннюю структуру базы данных (структуру) из другого мира. Я думаю, что это еще один момент, который является безопасностью. Каждая фирма хочет иметь ограниченный доступ к некоторым данные на уровне таблицы (не на уровне строк). Второй момент: производительность. Лучше иметь много таблиц, чем один большой.

Так что я думаю, что лучше оставить таблицы каждой фирмы, как они есть, и создать представление для отчетов (я думаю):

CREATE view dbo.Client 
    as 
    SELECT ClientId= ClientId, FirmPrettyId = 'first' 
    FROM   dbo.FirstCompanyClient 
    UNION ALL 
    SELECT  ClientId = Client_Id, FirmPrettyId = 'second' 
    FROM      dbo.SecondCompanyClient 

или

ДОБАВЛЕНО:

alt text http://i34.tinypic.com/2yydonc.jpg

Используйте триггер или хранимую процедуру для создания следующего идентификатора для определенной фирмы и области («клиенты» или 'документы'):

UPDATE dbo.zz_IdGenerator 
    SET 
     @nextId = NextId, 
     NextId = @nextId + 1 
    WHERE FirmId = @firmId and Scope = @scope 

    RETURN @nextId; 

ОБНОВЛЕНО:

Вставьте UPDATE dbo.zz_IdGenerator... в хранимую процедуру, и называют его перед вставкой в ​​таблицы документов или клиента.

alt text http://i35.tinypic.com/dcro9g.jpg

Answer 2

Для обработки данных таблицы необходимо установить отношения PK-FK соответствующим образом. Например, если у Фирмы есть несколько документов (очевидно, фирма может), то в таблице DOcuments вы можете иметь FirmID как fk, который является PK из таблицы фирм. Или лучше всего изучать отношения - это сопоставление. Сделайте одно, создайте необходимые независимые таблицы без какой-либо взаимосвязи между таблицами. Скажем, у вас есть 4, тогда создайте 4 таблицы, которые будут Пользователями, Документами, Фирмами и Клиентами. Теперь создайте еще одну таблицу, которая будет обрабатывать отношения любых двух таблиц. Например. Doc и фирмы.

Craete новый стол DocFirmMapTable с тремя столбцами DocFirmMapId как его ПК, DocId, FirmId. Просто вам нужно позаботиться об этом, вставляя в эти две таблицы, вам нужно сделать еще одну вставку в своих соответствующих таблицах. Также в таблице карт вы можете сохранить отображение двух или более двух таблиц в соответствии с вашим требованием.

Answer 3

FWIW, мнение

• бы рекомендовать вам сохранить уникальный суррогатной PK всех таблиц для uniquess дизъюнктивно (т.е. Держите RowId в)
• Как вы предложили с «PrettyId», уникальная фирма «Sequence» документа, клиента и т. д. для каждой фирмы не будет ПК. Для этого вам понадобится отдельный шаблон счетчиков или аналогичный. Вы также можете принудительно применять уникальную ограничение (* PrettyId, FirmId) для каждой таблицы.
• Хотя не форма 4NF, может быть хорошей идеей для целей безопасности и здравомыслия, чтобы напечатать внешний ключ FirmId на ВСЕ ваши фирменные таблицы (Обоснование: почти каждый запрос, выданный вашей системой, вероятно, захочет фильтровать по FirmId). Это также даст преимущества в производительности, так как вы не обязательно должны присоединиться к первым соседям фирмы для того, чтобы сделать эту фильтрацию (и FirmId FK нужно будет вникать во все индексы.

НТН

Answer 4

Цель первичного ключа для однозначной идентификации строки в таблице, а не служить в качестве своего рода бизнес-ключ, который может иметь какое-то значение.

Если вам нужна пользовательская последовательность нумерации для каждого клиента, для этого может быть добавлен столбец (DocumentCustomId).

В Oracle, DB2, Postgresql может использоваться объект последовательности - на сервере SQL вы должны создать пользовательский секвенсор, а следовательно, таблицу DocumentSequence. Доступ к таблице должны быть через хранимую процедуру (ы), которые должны осуществлять

• create_sequence
• next_vale
• current_value
• previous_value

При установке нового документа, то DocumentId auto-increments, в то время как DocumentCustomId должен быть получен как next_value от объекта секвенсора.

Вот несколько ссылок на объекты последовательностей DB2, Oracle, Postgres помочь с концепцией.