ОК, у меня есть БД доступа, в которой есть таблица товаров и таблица студентов, которая содержит ежемесячную абонентскую плату, эти два связаны в третьей таблице «Платежи», которая собирает данные от Студента (плата + элементы) и суммируйте их. Но эта таблица сохраняет только значения, а не описание. Поскольку платеж является нерегулярным (студенту не нужно платить все в тот же день), и из-за этого стоимость долга предмета студента должна быть уменьшена как способ, которым он платит, мне нужен контроль над этим. Итак, следует ли мне создать новую таблицу, которая копирует данные из двух других таблиц и вносит изменения в эту новую или просто использует запрос для отображения данных и внесет изменения в «главную» таблицу? Я немного потерян и смущен в этом, так что извините этот беспорядок.Должен ли я создать таблицу или запрос?
ответ
Вам необходимо прочитать текст новичка о дизайне базы данных, прежде чем идти дальше с этим проектом, imo. Первая находкой прибегая к помощи «реляционной база данных учебника» является
http://www3.ntu.edu.sg/home/ehchua/programming/sql/relational_database_design.html
смотрите раздел «Создание Отношения между таблицами». В Интернете доступно множество других обучающих программ.
Как правило, вы не копируете данные из одной таблицы в другую. Часть информации, такая как описание элемента или имя пользователя, должна храниться только в одном месте в базе данных. Когда вам это нужно, в контексте связывания его с данными в другой таблице (например, чтобы отобразить описание записи в таблице «Элементы» со стоимостью в таблице «Платежи или платежи»), вы просматриваете ее, а не копируете.
Способ иметь дело со студентом, имеющим достаточно много элементов, состоит в том, чтобы иметь таблицу «ссылок», которая в основном хранит только уникальный идентификатор ученика и уникальный идентификатор элемента. Обычно это будут числовые идентификаторы, которые назначаются, так как теперь учащиеся/предметы/другие объекты добавляются в db.
Пункт наличия таблицы ссылок состоит в том, что практического ограничения на количество элементов, которые могут быть связаны с конкретным учащимся, не существует.
Вы вызываете добавление столбца в таблицу ссылок, чтобы связать учащегося и один или несколько экземпляров одного и того же элемента с конкретными счетами (или или заказы или что бы то ни было, что ваш db моделирует).
Извините, в действительности я не имею в виду копию, но ссылку, да. Я связываю эти несколько таблиц с идентификатором, и все работает нормально. Единственная проблема связана с нерегулярной оплатой. –
Ну, вам нужно рассказать нам, в чем проблема с нерегулярными платежами? Какие «бизнес-правила» вы пытаетесь применить к ним и почему это проблема? – MartynA
OK, обычно, когда у вас есть такая подписка + элементы, все они суммируются в конце месяца, и вы платите за это значение, не так ли? Здесь вам нужно только оплатить подписку. Для предмета предположим, что это тренажерный зал, и вы покупаете рубашку, это цена составляет 10 долларов США, но вы можете заплатить это значение в любой день месяца, и вы можете заплатить как 2 доллара в понедельник, 7 долларов в среду и 1 доллар США за пятницы. Я знаю, что это не имеет никакого смысла, но так работает владелец. –
О, проблема с созданием новой таблицы заключается в том, что нет способа узнать, сколько предметов у учеников. –
Похоже, вы копируете много данных через таблицы здесь (что обычно плохое), и это действительно запутывает то, что вы на самом деле пытаетесь сделать. Может быть, вы можете показать простой пример? – David
См.: Http://stackoverflow.com/help/how-to-ask –