Общие > Базы данных

Связь многие-ко-многим между двумя таблицами?

<< < (4/5) > >>

Kwazar:
Вопрос приведен именно в авторской постановке.
А оптимизация. Дело в том, что когда я с заказчиком беседовал, он мне сказал, что бы я придерживался того для БД, что он уже спроектировал. Но если учесть еще несколько сервисов, предусмотренным заказом, то для их интерации придется вводить минимум 2 лишние таблицы, со многими повторяющимяся данными. Смысла нету. Если спроектироваль все несколько иначе, то можно уменьшить количество таблиц, упростить sql запросы. Так как информации будет меньше в базах - отработка будет быстрее. Она будет в любом случае быстрая, однако я просто стараюсь сделать все проще и удобнее.
Я не говрю, что тот закачик туп или глуп - свое дело он знает. дело в том, что оно надо так извращаться?

win_pup:
я бы спроектировал базу след.образом:

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

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:
Кстати. Между делом... На тестовом задании, которое я здесь выложил - нельзя было создавать лишние таблицы.
Можно было оперированть только теми, что имеются на данный момент.

Chs:

--- Цитировать ---Кстати. Между делом... На тестовом задании, которое я здесь выложил - нельзя было создавать лишние таблицы.
Можно было оперированть только теми, что имеются на данный момент.

--- Конец цитаты ---

Вопрос подразумевал LEFT JOIN.

Kwazar:
А чем плох такой подход:
SELECT number,product_name,customer_id FROM products, accounts USING
(product_name) WHERE
customer_id=\'$login\'.
ХОТЬ СУБД и используют внутренний оптимизатор, однако я предпочитаю делать
более точные и понятные для чтения запросы. К тому же, если в таблицах будут
другие стобцы с одинаковыми именами, то без него сложно будет обойтись.
Форма USING принимает список имен столбцов, разделенных запятвыми, где
каждое имя соответствует одному столбцу в каждой из соединяемых таблиц,
выполняет эквисоединение по всем парам столбцов с одинаковыми именами и
объединяет результаты с помощбю оператора AND. Это практически анологично
NATURAL JOIN, за исключением того, что USING использует только указанные
столбцы.
Можно также добавить INNER JOIN. При внутреннем соединении несовподающие
строки обеех таблиц исключаются.
(синтаксис привеен стандартный, а не конкретный для определенной СУДБ)
???

Навигация

[0] Главная страница сообщений

[#] Следующая страница

[*] Предыдущая страница