В зависимости от условия, таблица объединяется с другими по разным столбцам. Вопрос?

[Гриша К.]

В зависимости от условия, таблица объединяется с другими по разным столбцам. Вопрос?

Здравствуйте.

Есть таблица БД (пример):

CREATE TABLE order (
    order_id int(11) NOT NULL auto_increment,
    delivery_id int(11) NOT NULL,
    warehouse_id int(11) NOT NULL,
    order_type tinyint(4) NOT NULL,
  PRIMARY KEY  (order_id),
  KEY delivery_id (delivery_id), 
  KEY warehouse_id (warehouse_id)
)

# 1) Если order_type=0: 
SELECT *
FROM order, delivery
WHERE order.delivery_id = delivery.delivery_id

# 2) Если order_type=1: 
SELECT *
FROM order, warehouse
WHERE order.warehouse_id = warehouse.warehouse_id

ВОПРОС: с учетом приведенных примеров выше, допустима (правильна) ли такая структура базы данных, что в зависимости от условия, таблица объединяется с двумя разными таблицами (по очереди) по разным полям???

Либо правильнее будет delivery_id и warehouse_id, вынести в 2 отдельные таблицы:

CREATE TABLE order_to_delivery (
    order_id int(11) NOT NULL,
    delivery_id int(11) NOT NULL,
  KEY  (order_id),
  KEY delivery_id (delivery_id)
)
CREATE TABLE order_to_warehouse (
    order_id int(11) NOT NULL,
    warehouse_id int(11) NOT NULL,
  KEY  (order_id),
  KEY warehouse_id (warehouse_id)
)

 

[zerkms]

UNION

 

[Гриша К.]

zerkms, спасибо за ответ.

То что UNION объединяет множество SELECT в один результат, я знаю. Его придется применять в любом из приведенных вариантов.
Вопрос состоит в том, какой из вариантов структуры БД выбрать. Сейчас я уже выбрал второй вариант структуры БД (сделав 2 доп. таблицы), но мне все же интересно приемлем ли первй вариант структуры БД с одной таблицей?

 

[alpine]

Гриша К.
Ты не написал чем конкретно тебя первый вариант не устроил и чем устроил второй. И это плохо.

-~{}~ 07.01.07 16:19:

Можно вполне применять и первый вариант. Только более логично если таблица имела бы структуру:
[sql]
CREATE TABLE order (
order_id int(11) NOT NULL auto_increment,
id int(11) NOT NULL,
order_type tinyint(4) NOT NULL,
PRIMARY KEY (order_id),
KEY id (id),
KEY order_type (order_type),
)
[/sql]
Потому что связка id - order_type однозначно определяет то что там у тебя заказывается, как мне кажется.

 

[Гриша К.]

alpine, спасибо за ответ.
Если я правильно вас понял, то предложенная вами структура подразумевает, что данные записываемые в столбцы "delivery_id" и "warehouse_id", будут записываться в один столбец, в зависимости от "order_type" таблица будет объединяться по столбцу "id" с другими таблицами.

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

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

 

[Krishna]

Вопрос, как и ответы нелепые.

Сам вопрос схож с примерно таким: "Какое мороженое лучше: большое или шоколадное"?

Аффтару вдумчиво читать про нормальные формы, про отношение 1 к М и М к М и главное, понять, что

допустима (правильна) ли такая структура базы данных,

это на самом деле нелепый вопрос, при отсутствии уточняющих требований.

 

[Гриша К.]

Krishna, ваш ответ я прочитал, но не понял.

alpine, я обдумал ваш вариант, + мне привели схожий пример структуры БД, который используется в программе работы с банковскими операциями, буду наверное использовать такой вариант (подумаю еще).

 

[Krishna]

Гриша К.
В двух словах попроще: у Вас нет достаточного понимания теории реляционных БД для самостоятельного ответа на заданные вопросы. А если будут просто отвечать "так правильно" или "так неправильно", то скорее всего это будут делать люди сами плохо разбирающиеся в вопросе, ибо вопрос поставлен некорректно, а потому правильного ответа не имеет. Какие конкретно темы нужно изучить для начала по текущему вопросу - я написал, но вообще советую взять книжку по теории реляционных СУБД (а не мануал MySQL / MySQL за 24 часа) и мужественно её осилить. И тогда снизойдет невиданное озарение И потраченное время на чтение вернется лихвой, компенсируя форумную переписку и неуверенность в своих действиях.

 

[Гриша К.]

Krishna, спасибо за разъяснения. Согласен, конечно надо мне почитать побольше материала по организации структуры БД, и это придется сделать.

Но в приведенном случае есть всего несколько вариантов решения, и те люди которые встречались с подобными задачами, могут дать ответ, потому как сделали они и как у них работает. Человек не с форума который дал мне совет, использует структуру, схожую с примером приведенным alpine, единственное что данные другие, и используется данная структура в БД программы АС-филиал Сбербанка России, используемой во всех филиалах Москвы И МО и в очень многих филиалах по России - поэтому можно сказать что данный вариант структуры приемлем и допустим для использования.

 

[chira]

Гриша К.

Ты привёл две структуры и спрашиваешь какая правильнее, ни слова не сказав, к чему эти структуры. Мы можем догадываться о чём речь, только из названия таблиц.
Если бы ты немного объяснил, что orders - у тебя заказы чего-то ... и т.д.
почему нужно объединять orders,delivery и orders, warehouse и почему при этом нельзя держать delivery и warehouse в одной таблице с дополнительным полем type?

 

[Гриша К.]

chira, да с объяснения на форуме я навернека накосячил. Спасибо, тем кто всетаки отвечал мне.

Суть такая:
Таблица "ORDER" - это таблица заказов,
столбец "order_type" - это тип заказа (0 - доставка, 1 - самовывоз).

При оформление заказа, пользователь выбирает тип заказа,
если "Доставка", то для него выводяться способы и условия доставки из таблицы "DELIVERY",
если "Самовывоз", то для него выводяться адреса пунктов получения товара из таблицы "WAREHOUSE".
После подтверждения пользователем оформления заказа,
в таблицу "ORDERS" (и в сопутсвующие таблицы, например таблица состава заказа) записываются данные о заказе: тип заказа -> в соответсвии с типом заказа записывается ИД доставки или самовывоза, и другие данные (плательщик, сумма и т.д.).

Приведу ссылку на визуальный пример: http://magazin.pozvonochnik.info/cart/?option_value_id%5B1%5D=23&option_value_id%5B5%5D=14&price_id=20

 

[chira]

Гриша К.

я бы сделал вместо двух таблиц "Доставка", "Самовывоз" одну - "Способ получения товара" или "Контактная информация" с полем type = [D|S] (D-доставка, S-самовывоз).
твои таблицы отличаются друг от друга одним полем "адрес доставки", в случае самовывоза оно будет NULL.

-~{}~ 09.01.07 15:45:

о WAREHOUSE у меня (как программера) другое представление ...

 

[Гриша К.]

chira, спасибо за ответ.
В моем случае таблицы доставка и самовывоз, различаются по структуре:
- таблица "Доставки" содержит ИД вида доставки (Москва, МО, Россия), способ доставки, описание и цену.
- таблица "Самовывоз" содержит адрес получения товара, схему проезда (ИД изображения), описание проезда, описание для купона (на получение скидки).
Но ваше предложение я в общем-то понял, и всетаки проанализирую его, спасибо за совет.

/* В переводчике "WAREHOUSE" я получил перевод "СКЛАД", склад готовой продукции в английских словосочетаниях содержит также это слово. С английским у меня туговато, а что с точки зрения программера что это значит я не знаю, поскольку я маленький программер )) */

 

[chira]

WAREHOUSE для обычных людей это склад, я сталкивался с DATA WAREHOUSE т.е. хранилище данных.
в твоём случае я подумал, что DELIVERY - это актуальные заказы, а WAREHOUSE законченные, обработанные и "отправленные" в архив или на склад данных ...

 

[Гриша К.]

chira, спасибо за разъяснения ))