MS Access 07 - столбец поиска по сравнению со многими ко многим;Q re флажки в формах многие ко многим

Question

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

Вопрос 1 В чем разница, если она есть, между использованием столбца «Уточняющий запрос» и таблицы «многие ко многим»? Пример: у меня есть таблицы «Учитель» и «Тема». У многих учителей много предметов. Я могу создать таблицу Teacher_Subject и выполнять запросы с этим. Затем я создал справочную колонку в таблице учителей с данными по предметам. Похоже, что столбец поиска занимает место таблицы teacher_subject. (хотя данные о взаимоотношениях явно дублируются между справочной таблицей и teacher_subject и могут различаться). Какой вариант «лучше»? Есть ли проблема с использованием справочных таблиц? (Я понимаю, что это очень «общий» вопрос. Ссылки на другие ресурсы и ответы, говорящие «это зависит ...», приветствуются)

Вопрос 2 Что привлекает меня в таблицах поиска, так это следующее: при создании формы для ввода предметов для учителей с помощью поиска я могу просто создать флажки и щелкнуть тему для учителя «включено» или «выключено». Каждый клик вкл / выкл создает / удаляет запись в столбце поиска (который заменяет teacher_subject). Если я использую форму из запроса от предмета учителя с учителем в качестве основной формы и предмета в качестве подчиненной, я сталкиваюсь с этой проблемой: В подчиненной форме я могу выбрать любой предмет, который есть у учителя, в поле Bombo, то есть нажать, прокрутить вниз, выбрать , перейти к следующей строке, щелкнуть, прокрутить вниз и т. д. (занимает слишком много времени) ИЛИ Я могу создать список, в котором перечислены все доступные темы в каждой строке, но можно выбрать только одну. (занимает слишком много места). Возможно ли иметь список включения / выключения для учителя_субъекта, создавая / удаляя там записи с каждым кликом?

Примечание. Я знаю ноль SQL или VB. Если правильный ответ «вам нужно знать SQL для этого», то это круто. Мне просто нужно знать.

Спасибо!

Answer 1

Поиск столбцов в таблицах вызовет у вас больше стресса, чем радости. Если они вам не нужны для Sharepoint, их следует избегать. Вы можете прочитать http://r937.com/relational.html и http://www.mvps.org/access/tencommandments.htm

Answer 2

Я не совсем понимаю ваш второй вопрос, но мне кажется, что вам нужна подчиненная форма с выпадающим списком.

Если вы хотите сделать галочку, это быстро становится намного сложнее.Для меня вы начинаете с пользовательского интерфейса и работаете в обратном направлении к структуре, вместо того, чтобы идти в другом направлении.

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

Я бы хотел, чтобы MS сделала список с элементом управления флажком, который используется с полями MV, доступным для всехсписки, но привязка их к таблице объединения «многие ко многим» была бы сложной, если бы элемент управления списком не был предназначен для этого (например, со свойствами дочернего элемента / основного элемента ссылки).

Answer 3

Я бы не стал их использовать. Ваш пример в порядке, но есть ограничения. Что вы делаете, когда вам нужно сослаться на другое поле из таблицы Subject, кроме имени? Как бы вы дифференцировали предметы, предлагаемые только на семестр?

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

Другое ограничение - это когда вы начинаете определять, кто преподавал какие курсы в течение данного учебного года.

Answer 4

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

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

Тем не менее, я не знаю, если это то, что вы хотели бы заняться. Ранее вы указывали на готовность изучать SQL при необходимости; подход, который я предлагаю, также потребует VBA. Возможно, взгляните на статью Дэнни Лесандрини Создание наборов записей ADO в памяти , чтобы узнать, можно ли это использовать.

OTOH, возможно, наиболее подходящий для вас ответ - сохранить поля с несколькими значениями и продолжить свою жизнь. Я застрял. Но теперь, когда мы знаем, что вы на самом деле используете многозначные поля, возможно, кто-то другой сможет предложить вам более подходящее предложение.