Обойти ограничение 32 отношения на таблицу в Access - PullRequest
2 голосов
/ 16 июля 2009

Я пытаюсь создать базу данных для управления запасами, используя большое количество таблиц и принудительных отношений, и я только что натолкнулся на ограничение в 32 отношения (индекса) для таблицы Access (используя Access 2007).

Просто чтобы уточнить: проблема не в том, что таблица Employees имеет 32 явных индекса. Скорее проблема заключается в ограничении количества ссылок на таблицу Employee в ограничениях FOREIGN KEY. Например:

CREATE TABLE Employees (employee_number INTEGER NOT NULL UNIQUE)
;
CREATE TABLE Table01 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table02 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table03 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;

...

CREATE TABLE Table30 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table31 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table32 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
; 

В последней строке выше выдается исключение: "Не удалось создать индекс; определено слишком много индексов.

Какие варианты у меня есть, чтобы обойти это ограничение?

Я слышал, что создание дублирующейся таблицы с соотношением 1: 1 - это один из методов. Я новичок в разработке баз данных, поэтому, пожалуйста, поправьте меня, если я ошибаюсь; но с учетом таблицы Employees с 31 индексом я бы создал таблицу Employees2 (с одним полем?) с отношением 1: 1 к Employees и связями с этой новой таблицей из любых оставшихся связей, в которых EmployeeID является внешним ключом. Каков наилучший способ обеспечить заполнение второй таблицы рядом с первой?

Есть ли другой подход?

Из-за нехватки доступной информации может показаться, что это может быть редкой проблемой с правильно спроектированной базой данных, или решение известно. Прости новичка!

Обновление : Непосредственный консенсус заключается в том, что мой дизайн провален или слишком амбициозен. Это вполне может иметь место. Тем не менее, я бы предпочел провести общее обсуждение проекта в рамках отдельного вопроса, так что, ради аргумента, может кто-то ответить на этот вопрос? Если ответ просто «Никогда не делай этого», мне придется принять его.

Ответы [ 4 ]

3 голосов
/ 16 июля 2009

Я сталкивался с этим ограничением несколько раз в своих приложениях. И я могу заверить другие постеры, что мои приложения очень хорошо разработаны.

Одна проблема заключается в том, что Access создает индексы из-за отношений и полей поиска, которые нельзя просмотреть в основном окне свойств индекса, но они доступны через коллекции DAO. Эти индексы часто являются дублирующими индексами для индексов, которые вы также создали.

У меня есть инструмент, состоящий из нескольких форм, которые вы импортируете в свою BE MDB, который позволяет вам удалять дубликаты индексов. Поскольку я еще не сделал это доступным на моем веб-сайте, пожалуйста, напишите мне об этом.

2 голосов
/ 19 июля 2009

Я бы предложил просто не определять все отношения / индексы для реализации отношения 1: 1, чтобы обойти это. Ни одно из решений не является оптимальным, но позднее оно создаст гораздо большую нагрузку на обслуживание и потенциал аномалий данных.

Я не собираюсь критиковать дизайн так быстро, как некоторые другие, но он меня заинтриговал. Не могли бы вы перечислить поля таблицы сотрудников, которые являются внешними ключами? Есть большая вероятность, что некоторая нормализация в порядке, и, возможно, некоторые умные люди в SO могли бы сделать некоторые предложения по дизайну, чтобы обойти эту проблему.

1 голос
/ 16 июля 2009

Мне трудно поверить, что для таблицы Employee потребуется 32 индекса; если это действительно так, вам следует рассмотреть возможность перехода по крайней мере на SQL Express.

0 голосов
/ 16 июля 2009

... я бы создал таблицу Сотрудники2 (с одним полем?) Со счетом 1: 1 отношения с сотрудниками и отношения к этой новой таблице из любые оставшиеся отношения, в которых EmployeeID - это внешний ключ.

Это выполнимо. Предположительно ваша основная таблица может иметь поле Autonumber в качестве первичного ключа, или вы генерируете индексный номер. Ваша таблица Employees2, очевидно, должна отражать это.

Какой лучший способ обеспечить Второй стол заполняется рядом первый?

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

...