Автор Тема: Связь многие-ко-многим между двумя таблицами?  (Прочитано 7425 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Kwazar

  • Философ
  • Постоялец
  • ***
  • Сообщений: 201
  • +0/-0
  • 2
    • Просмотр профиля
    • http://www.uhuhu.ru/
Вопрос приведен именно в авторской постановке.
А оптимизация. Дело в том, что когда я с заказчиком беседовал, он мне сказал, что бы я придерживался того для БД, что он уже спроектировал. Но если учесть еще несколько сервисов, предусмотренным заказом, то для их интерации придется вводить минимум 2 лишние таблицы, со многими повторяющимяся данными. Смысла нету. Если спроектироваль все несколько иначе, то можно уменьшить количество таблиц, упростить sql запросы. Так как информации будет меньше в базах - отработка будет быстрее. Она будет в любом случае быстрая, однако я просто стараюсь сделать все проще и удобнее.
Я не говрю, что тот закачик туп или глуп - свое дело он знает. дело в том, что оно надо так извращаться?
С уважением Сергей

Оффлайн win_pup

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 18
  • +0/-0
  • 0
    • Просмотр профиля
    • http://
я бы спроектировал базу след.образом:

таблица Покупатель:

customer
-------------------------
id_customer (key)
name

таблица Товар:

product
-------------------------
id_product (key)
name

таблица Заказ:

order
-------------------------
id_order (key)
id_customer

ну и конечно же таблица, осуществляющая связь многих-ко-многм (в заказе несколько продуктов, вид товара может быть учтён в разных заказах):

order_product
-------------------------
order_id (Key)
product_id (Key)

Нет никаких ни аномалий ни избыточности, мне кажется...

Оффлайн Kwazar

  • Философ
  • Постоялец
  • ***
  • Сообщений: 201
  • +0/-0
  • 2
    • Просмотр профиля
    • http://www.uhuhu.ru/
Кстати. Между делом... На тестовом задании, которое я здесь выложил - нельзя было создавать лишние таблицы.
Можно было оперированть только теми, что имеются на данный момент.
С уважением Сергей

Оффлайн Chs

  • Perl программер
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 1108
  • +0/-0
  • 2
    • Просмотр профиля
    • http://chs.now.at/
Цитировать
Кстати. Между делом... На тестовом задании, которое я здесь выложил - нельзя было создавать лишние таблицы.
Можно было оперированть только теми, что имеются на данный момент.

Вопрос подразумевал LEFT JOIN.
2B OR NOT 2B = FF

Оффлайн Kwazar

  • Философ
  • Постоялец
  • ***
  • Сообщений: 201
  • +0/-0
  • 2
    • Просмотр профиля
    • http://www.uhuhu.ru/
А чем плох такой подход:
SELECT number,product_name,customer_id FROM products, accounts USING
(product_name) WHERE
customer_id=\'$login\'.
ХОТЬ СУБД и используют внутренний оптимизатор, однако я предпочитаю делать
более точные и понятные для чтения запросы. К тому же, если в таблицах будут
другие стобцы с одинаковыми именами, то без него сложно будет обойтись.
Форма USING принимает список имен столбцов, разделенных запятвыми, где
каждое имя соответствует одному столбцу в каждой из соединяемых таблиц,
выполняет эквисоединение по всем парам столбцов с одинаковыми именами и
объединяет результаты с помощбю оператора AND. Это практически анологично
NATURAL JOIN, за исключением того, что USING использует только указанные
столбцы.
Можно также добавить INNER JOIN. При внутреннем соединении несовподающие
строки обеех таблиц исключаются.
(синтаксис привеен стандартный, а не конкретный для определенной СУДБ)
???
« Последнее редактирование: 05 Марта 2003, 19:33:33 от Kwazar »
С уважением Сергей

Оффлайн win_pup

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 18
  • +0/-0
  • 0
    • Просмотр профиля
    • http://
если уж так, то мне кажется, что лучше в таблице account хранить не product_name, а product_id и объединять эти таблицы по id-шнику (using product_id)... а может я и ошибаюсь...

кстати, а какое(ие) поле(я) в таблице account у тебя являе(ю)тся ключевым(и)?

Оффлайн Kwazar

  • Философ
  • Постоялец
  • ***
  • Сообщений: 201
  • +0/-0
  • 2
    • Просмотр профиля
    • http://www.uhuhu.ru/
win_pup, точно :D
Основная таблица пользователя должна содержать только родительские ключи и персональную информацию по посетителю.
Далее таблица с id заказа товара будет содержать сам заказ.
Т.е. id заказа - id товара
Далее id понадобится для проверки по таблице - наличие на складе и т.д и т.п. заморочек много. Информации тоже. Но дублируются только ключи - связь между таблицами. Остальная инфа остается уникальной. Так проще.
С уважением Сергей

Оффлайн win_pup

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 18
  • +0/-0
  • 0
    • Просмотр профиля
    • http://
конечно :-)

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28