Несколько ссылок между двумя столбцами таблиц ... плохой подход к дизайну?

Question

Здравствуйте, я разрабатываю веб-приложение и собираюсь создать базу данных, я столкнулся с этим вопросом.Плохо ли иметь более 1 ссылки между двумя таблицами?Картинка, которую я разместил, является очень быстрым и маленьким примером, чтобы прояснить ее.Если я хочу отобразить все предложения, я хотел бы также вставить продукты, к которым они относятся, в этом случае я мог бы получить название продукта, создав экземпляр продукта, полученный с идентификатором продукта из поля идентификатора продукта в предложении.объект, но это потребовало бы большего количества запросов и большего количества печатной работы, поэтому я думал включить название продукта непосредственно в предложение, чтобы я мог просто получить все предложения и в конечном итоге отобразить связанный продукт, просматривая БД с идентификатором продукта.Считаете ли вы это плохим подходом?Я искал случаи, подобные моему, но я нашел только подходы с 1 соединением между таблицами (с уникальными идентификаторами). Спасибо

Answer 1

да, это было бы плохо.

удаление избыточного имени было бы правильной нормализацией. просто ссылку на идентификатор, это будет лучший способ.

Answer 2

В общем, нет ограничений на количество отношений (связей) между двумя таблицами, но каждое отношение должно иметь уникальное значение.Если в вашем примере Product Name и Product ID оба являются ключами-кандидатами и каждое имя всегда имеет один и тот же идентификатор, то определенно не должно иметь две связи PK / FK между этими таблицами.

Answer 3

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

Используйте идентификатор в таблице предложений, чтобы найти название продукта в таблице продуктов.

Answer 4

@ Джо прав.Нормализация - лучший подход к проектированию баз данных.Причина в том, что добавления, удаления и модификации полей могут быть сделаны только в одной таблице, а затем распространены через остальную часть базы данных через определенные отношения.