авторт.е. "Спецификация состав" это некая промежуточная таблица (временная) используемая как буфер? Что-то я запутался совсем

Нет конечно.

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

AshoorupВозникает у меня проблема с сохранением записей за конкретным пользователем.
Т.к. приложение теперь многопользовательское и база одна, то разумно предположить, что одновременно несколько человек будут добавлять свои записи в таблицу Specification line. Остается только закрепить конкретные строки за конкретным пользователем+еще кучу полей идентификации конкретной спецификации.

Сначала я думал сделать временный массив для каждого пользователя, который после набора определенного оборудования из таблицы Equipment catalog нажмет сохранить и весь массив скопируется в таблицу Specification line. Тогда в таблице Specification вместо поля ID_Specification line нужно два поля - начало и конец записи конкретной спецификации. Но тут возникает проблема когда другой пользователь запишет в таблицу Specification line свой диапазон записей вслед, а предыдущий решит добавить еще записей. Вобщем идея не катит. Ну не перелопачивать же все записи, двигать там и пр...

Следующая идея хранить в таблице Specification в поле ID_Specification line список записей (ID_Specification line из таблицы Specification line) пользователя. Тогда всё равно где находится запись. Единственное меня смущает, если пользователь удалит запись(и) и в таблице Specification line образуются "дыры". Другому пользователю я не знаю как "сообщить" про "дыру" в таблице, чтоб он туда писал. Со временем "дыр" может стать больше чем записей, т.к. процесс формирования спецификации пользователем дело долгое с постоянными правками.

Возможно несу ерунду, и все можно решить гораздо более практично. Прошу подсказать что делать
Несете ерунду.
У вас Specificafion_Line (пробелы - то в именах зачем ? штоб все время скобки ставить ?) и Specification сделаны с точностью до наоборот. Айди из Specification должен быть в качестве ФК в Specificafion_Line. ОДНА спецификация содержит МНОГО записей по оборудованию. В форме данные Specification будут в шапке - мастер запись. Детальные записи Specificafion_Line во вложенной форме-табличке, связанные через ID_Specifiaction. Это самые азы, они описаны во всех учебниках.

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

Есть команда приложения "Создать спецификацию" - кнопка, пункт меню, ... Нажали! Открылась форма спецификации с шапокой и детальной табличкой. Задали в шапке основные данные спецификации. Пользователь автоматически триггером записался поле ID_User. Наполнили спецификацию позициями из каталога. Ффсе, можно закрывать форму. Через айди мастер-записи позиции спецификации неотрывно связаны с самой спецификацией.

Продолжение.

Чуть по-другому, если ОДНА спецификация будет правится НЕСКОЛЬКИМИ пользователями и вы хотите это фиксировать. Здесь на форуме по проектирования и по MS SQL есть масса готовых рецептов аудита. Я в свое время выбрал один, достаточно простой.

Каждая прикладная таблица имеет поля:
InsertUserID - кто создал
InsertDatetime - дата создания
SaveUserID - кто последний сохранил
SaveDatetime - дата последнего сохранения

для практических разборок этого оказалось достаточно. Эти поля добавляются автоматическим скрипом вместе с заполняющим их триггером, когда таблица регистрируется как прикладная.

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

Если ваша спецификация и позиции спецификации будут иметь подобны поля, то вы тоже сможете контролировать этот процесс. На таблицы спецификаций и позиций спецификации можно повесить бизнесовый триггер, который будет запрещать редактирование, если спецификация уже распечатана. Пока то что нарисовали не выходит за рамки простой демонстрационной/учебной базы Борей/Northwind, которую Микрософт долго включала в поставку своего офиса (аксес). Был также клиент-серверный вариант этой базы - фронт Access ADP, клиент - MS SQL сервер. Можете нагуглить, скачать и посмотреть. Там все формы работают.
http://www.microsoft.com/en-us/download/details.aspx?id=23654

Переключите все таблицы на диаграмме в режим кастом, задайте для кастомного режима вывод имя, тип и ОПИСАНИЯ к полю. Рядом с каждой таблицей создайте комментарий и в одном-двух абзацах опишите смысл таблицы и ее главный особенности. Тогда штатный редактор диаграмм станет хорошим рабочим инструментом проектирования.

Сущность объект строительства надо выносить в отдельную таблицу и, видимо, сильно развивать.
С полями типа бит в некоторых клиентах могут быть проблемы. Я бы делал кондово nvarchar(1) Y/N. Смысл экономить биты...

AshoorupНасчёт "Сущность объект строительства":
Мне кажется достаточно описания в таблице Specifications, хотя под один объект (номер объекта, наименование объекта, объект строительства) может быть от 1 до 5 спецификаций. Может и стоит сделать отдельную таблицу под объект...
Абсолютно категорически делать отдельную таблицу.

AshoorupЗабыл написать:
- с одной спецификацией будет работать 1 пользователь. Такого точно не будет, что с одной спецификацией одновременно будет работать несколько пользователей.
- одну спецификацию может делать несколько пользователей. Тут все просто как мне кажется. Пользователь чья спецификация, или администратор может назначить другого пользователя для редактирования этой спецификации.
Этого достаточно. Если хотя бы раз несколько пользователей могут менять спецификацию или ее состав - надо хранить информацию о пользователе в таблице позиций спецификаций. Примеры полей я приводил выше. Их добавление и заполнение во всех прикладных таблицах ничего не стоит - работает один раз сделанный автомат. С учетом того, что предполагается реальное, производственное использование - я бы обязательно сделал такой простой и компактный аудит.

авторВот только я не понимаю насчет одинаковых полей. Для примера напишите хотя бы несколько как например можно было бы именовать их.

Во многом дело вкуса. Применительно к вашей задаче я бы сделал такие имена:

EquipmentID Идентификатор оборудования
EquipmentName Наименование оборудования
EquipmentModel Тип и марка оборудования
EquipmentCode Код оборудования
ManufacturerID Идентификатор завода-изготовителя
MeasureUnitID int Идентификатор единиц измерения
EquipmentWeight float Масса оборудования в килограммах
EquipmentDimension Габаритные размеры оборудования
EquipmentDiscontinuedFlag Снято с производства
EquipmentImage Изображение (фото/чертеж) оборудования
EquipmentDescription Описание оборудования
EquipmentNote Примечание к оборудованию сделанное пользователем "Редатктор БД"

Заводы-изготовители Manufacturer

ManufacturerID Идентификатор завода-изготовителя
ManufacturerName Краткое наименование завода-изготовителя
ManufacturerDescription Описание завода-изготовителя (адрес)
ManufacturerLogo Логотип завода-изготовителя

Единицы измерения MeasureUnit

MeasureUnitID int Идентификатор единиц измерения
MeasureUnitName Сокращение единицы измерения

Строка спецификации SpecificationLine

SpecificationLineID Идентификатор строки спецификации
EquipmentID Идентификатор оборудования
EquipmentCount Количество заказываемого оборудования
SpecificationLineNote Примечание

Спецификация Specification

SpecificationID Идентификатор спецификации
UserID Идентификатор пользователя
SpecificationTypeID Идентификатор типа спецификации
SpecificationStatusID Идентификатор статуса спецификации
ObjectID Номер объекта строительства

Статусы спецификации SpecificationStatus

SpecificationStatusID Идентификатор статуса спецификации
SpecificationStatusName Наименование статуса спецификации

Типы спецификаций SpecificationType

SpecificationTypeID Идентификатор типа спецификации
SpecificationTypeCode Тип спецификации (сокращенно)
SpecificationTypeName Наименование спецификации (для штампа)

Однообразно до отвращения - чем и хорошо. Таблица в единственном числе. Суффиксы -
ID - автосчетчик
Code - код, шифр, номер
Name - наименование
Description - длинное описание


авторИ насчет проблем с полями типа bit недопонял. У меня все прекрасно работает... Редактор БД будет ставить птичку если оборудование снято с производства. Возможно потом сделаю розовую подсветку строки, если оборудование снято с производства - для большей наглядности.
В некоторых клиентах МОГУТ быть проблемы. С кодом Y | N проблем быть не может. Если есть выбор дороги, на которой заведомо нет граблей, то я иду по ней.