Проблемы с разделением большой базы данных - PullRequest
0 голосов
/ 08 мая 2020

Мне интересно, может ли кто-нибудь иметь представление о проблеме, с которой я столкнулся ....

У меня есть база данных в Access 2016. Все еще на стадии разработки, но по сути это инструмент отчетности для пакетных процессов мэйнфрейма. Дело в том, что он большой. У меня есть одна таблица в формате c, в которой хранятся данные о событиях, которые в настоящее время составляют чуть более 1 миллиона строк.

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

При каждой попытке я получаю сообщение об ошибке «Ключ поиска не найден ни в одной записи». Просматривая онлайн, я вижу, что в большинстве случаев это происходит из-за какого-либо вида повреждения, и наиболее частым ответом является начальный пробел в имени поля. Я просмотрел каждую таблицу и каждое поле, пробелов не нашел. Уплотнял и ремонтировал несколько раз. Все в базе данных работает нормально, ошибок не наблюдается, все формы, запросы, макросы и код работают без единой проблемы, но у мастера разделения каждый раз возникает проблема. Удаляю половину строк в таблице, и все работает.

Есть ли в Access проблема с разделением больших таблиц? Мне нужно разделить меньшее количество данных, а затем импортировать их обратно? Достаточно просто, но мне интересно, может быть, я где-то получаю повреждение, которого я просто не вижу ни в каком коде или возвращаемых запросах?

Спасибо, Горд

1 Ответ

0 голосов
/ 08 мая 2020

Что ж, как только вы разделитесь, вы должны продолжать развивать разделение. Есть немного (если нет причин), чтобы go вернуться к неразделенной модели разработки. И прелесть такой настройки в том, что тогда ваша часть разработки и приложения будет ОЧЕНЬ маленькой.

Нет необходимости пытаться разрабатывать с каким-то большим слоном в одной комнате.

Другой бонус?

Ну, по большей части «большинство» вещей работает нормально при разделении, но есть несколько вещей, которые работают «немного» по-другому. В результате вы не хотите тратить, скажем, неделю или месяц на разработку. Разделите и затем найдите 20+ ошибок. Другими словами, разделение на раннем этапе цикла разработки означает, что вы ОСТАЕТЕ разделение на оставшуюся часть жизненного цикла этого проекта.

Когда вы только начинаете?

Ну, потому что вы проектируете и меняете структуры таблиц так много? Что ж, тогда, если разделить, эта часть цикла разработки будет БОЛЬШЕ болезненной, если разделить.

Если разделить? Затем, чтобы изменить структуру таблицы, вы:

Выйдите из внешнего интерфейса (FE)

Откройте задний конец (BE). Добавьте столбцы, возможно, создайте или настройте отношения и т. Д. c. Может быть, даже добавить новую таблицу. Эй, какая-то таблица большая, и вы ищите по столбцу? Затем добавьте индекс. Итак, ваше «общее» ведение данных, компактный ремонт и т. Д. c.? Все сделано в этом BE.

Хорошо, все в порядке?

Теперь закройте заднюю часть.

Теперь вы go вернулись к своему интерфейсу.

На этом этапе вам следует заново связать ваши таблицы. (Менеджер связанных таблиц делает это быстро и легко.)

А если вы добавили новые таблицы в серверную часть? Итак, вы снова используете менеджер связанных таблиц и добавляете эти новые таблицы.

Итак, «немного» дополнительной работы по сравнению с неразделенным.

Как уже отмечалось, скажем, в первую неделю, скажем,?

Вы создаете таблицы, изменение структур, добавление новых таблиц. Налаживание отношений. Итак, на данный момент все нормально и нормально работать без разделения. И у вас еще НЕ много данных, если их почти нет в системе, верно ???

Однако через очень короткое время изменения в таблице (структуры et c.) Успокоятся до глухой рев. Итак, самое время, когда вам следует разделиться.

ОДИН РАЗ разделившись, вы больше НЕ возвращаетесь к старой модели разработки без разделения.

И прелесть этой настройки? Что ж, вы можете работать с «тестовой» версией данных. Или переустановите ссылку на рабочую версию.

Итак, допустим, вы тестируете какой-то код для удаления строки данных. Что произойдет, если вы пропустите некоторые критерии и удалите все производственные данные?

Итак, работа без разделения в типичном цикле разработки Access? Вы делаете это только на короткое время, а затем, как только вы разделитесь, вы должны остаться неразделенными.

И это также позволяет ДЕЙСТВИТЕЛЬНО легко сделать резервную копию части вашего приложения (отдельно от данных). В начале дня вы можете перетащить копию своего рабочего приложения в «предыдущую» папку. Поскольку в приложении нет данных, оно будет довольно маленьким, поэтому его будет легко выполнить резервное копирование и сделать рабочую копию.

Есть МАЛЕНЬКАЯ причина для работы над красивым маленьким приложением с огромным слоном в комнате прикреплен (часть данных).

Итак, я настоятельно рекомендую после разделения не пытаться go вернуться в неразделенную базу данных.

Хорошо, что делать с это ошибка разделения?

Файл огромен, не разбивается с помощью мастера? Что ж, это очевидное - ЕЩЕ ОДНА ХОРОШАЯ причина оставаться разделенным!

Я бы сделал разделенное руководство. Шаги, которые выполняет мастер (или вы выполняете вручную), очень просты.

Итак, выйдите из интерфейса. Теперь создайте новую пустую базу данных для внутренних данных.

Теперь импортируйте таблицы из FE (внешний интерфейс).

Если импорт прошел нормально? Это означает, что вы дома бесплатно!

Выйдите, а теперь снова откройте FE.

Просто удалите таблицы в вашем интерфейсе. Теперь выполните сжатие.

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

Итак, вы можете разделить вручную - попробуйте.

И доставляете неприятности, которые у вас сейчас возникают? Что ж, это еще одна замечательная и веская причина держать вещи разделенными!

Итак, попробуйте ручное разделение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...