Наша группа хотела бы сохранить данные нашей спецификации в базе данных.Однако нам нужна некоторая помощь в проектировании базы данных.
Группа определилась с восьмистраничной спецификацией, в которой есть "пробелы" для по крайней мере ста отдельных значений.Несколько наборов значений отображаются в табличном формате.Если значение не указано, оно не распространяется на данный продукт.Каждое поле будет иметь определенный тип данных.Представлены все поля со следующими типами данных: целые числа, десятичные числа, справочный список, текст, дата и логическое значение.
База данных также должна отслеживать предыдущие изменения.
С общей точки зренияКак мне спроектировать базу данных?
Вариант 1. Одна или несколько таблиц «один-к-одному»
- Одна большая таблица с «ID» и «Rev» в качестве первичного ключа..
- Активная ревизия как ревизия с самой последней датой «подтверждено».
- Если число полей превышает лимит СУБД, разбейте таблицу на несколько полей «один к одному», каждое из которых имеет«ID» и «Rev» в качестве первичного ключа.
Вариант 2: Entity-value
- Основная таблица (ID, Rev)
- Для каждого типа данных:
<data_type> _категория таблицы, описывающая каждое поле этого типа данных <data_type> _значение таблицы (ID, Rev, категория, значение) для каждого экземпляразначение
Опция?: Любая идея, которую вы придумали ...
Примечание: Если применимо, я пLAN для использования MS-Access для всего проекта (форм, таблиц, запросов и отчетов).У нас также есть SQL Server и подписка MSDN, так что, если вы настоятельно рекомендуете, это вариант
РЕДАКТИРОВАТЬ:
- Это будет собственная база данных.
- У нас около 150 спецификаций, и я ожидаю около одной новойпересмотр каждой спецификации в год.
- Скорее всего, я буду вести эту базу данных по мере возникновения проблем.
- Приблизительно пять человек должны иметь возможность создавать и обновлять спецификации и редакции.
- ПриблизительноДвадцать пять сотрудников получат данные из этой базы данных (отчеты о печати, спецификации поиска и т. д.)
EDIT2: (разъяснения для HansUp)
- Я пересмотрю использование полей поиска и рассмотрю другие варианты (создание другой таблицы, текстовые значения и т. Д.)
- Под «каждым полем будет свой тип данных», я имел в виду, что каждое поле (или «пустое»)) будет иметь соответствующий тип данных.Например, MAX_CHAMBER_PSI всегда будет целочисленным значением, PERFORM_TEMPERATURE_TEST всегда будет Да / Нет, а REVISION_REASON всегда будет строкой.
- Количество пользователей является лишь приблизительным.Около пяти пользователей будут иметь доступ к созданию / обновлению, и около двадцати пяти дополнительных пользователей смогут только читать данные.В форме form_load я просто планировал скрыть элементы управления и обновить свойства в зависимости от пользователя, вошедшего в систему.
EDIT3: Сводка:
Мы разработали специальный отчет с~ 100 полей все зависят от SpecID и Rev для определения приемлемого диапазона для различных атрибутов наших продуктов.
В настоящее время спецификации пишутся от руки в отчете и хранятся в шкафу для хранения документов.Кроме того, копия последней версии каждой спецификации предоставляется в подшивке на каждом испытательном стенде.
Как мне моделировать первичный ключ с примерно сотней атрибутов, что превышает ограничение для столбцов в MicrosoftТаблица доступа?