alexeyvg,

ваще-то, таблицы товаров и заказов не должны быть связаны. Заказанный товар должен копироваться в заказ. Ситуация с товаром, может быть не сосвем понятна, но посмотрите на ситуацию с ценой заказа: сделали заказ по одной цене, а через месяц изменили цену товаров... и? все старые заказы стали по новой цене?

Товар, цена товара и объем заказа - это копированные данные из текущих таблиц и не должно там (в заказах) быть никаких "идентификаторов"... Заказ далее живет своей половой жизнью, никак на завися от товаров, складов, ценовой политики и т.д. :)

guest_20040621,

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

Говнокодерство, активно сменяется говнопроектированием... благо объемы и скорости вычислительных устройств позволяют. Зато потом, вопрошаем "таблица в миллион записей, поиск идет 30секунд... хотя там 80% это старое неактивное барахло, что делать?"

Копирование товара в заказ - никак не мешает его жизненному циклу. Решите этот вопрос на досуге самостоятельно, плиз.

alexeyvg, сам товар - такое же значимое поле. Сущность Цена - просто проявляет те же самые проблемы, значительно чаще и шустрее, но сами проблемы - в точности такие же.

пгуые123,

вот, вот... а можно пойти ещё дальше: Есть товар от поставщика1, он же от поставщика2... а поставщик3 вчерась переименовал свой товар, который заказали позавчера, но он ещё даже не поступил на склад...

Arhat109, неумение работать с данными (многие программисты SQL - программистами не являются, SQL - НЕ ЯП)

, приводит к тому, что "данные не удаляются никогда"... но как-то НАДО различать рабочие записи от мусора
... вот и появляется ТУПОЕ поле с признаком "Активная Запись"

... потому что, сборкой мусора, выделением памяти, и её управлением занимался на самом деле далеко не каждый. Это есстественное знание любого программиста на любом нормальном ЯП. В необходимый арсенал знаний SQL-пользователя - НЕ ВХОДИТ (и не должно в общем-то).

ещё раз (писал уже ранее) SQL - пользователь <> программист.

guest_20040621> ваще-то, таблицы товаров и заказов не должны быть связаны

Никогда никому об этом не говорите. Засмеют.


... вот тут 13510983 Вы сами советовали что-то подобное... уже засмеяли? :)

MasterZiv, данные - они всего лишь данные. И когда они больше не нужны БЛ, их можно (иногда и нужно, и даже необходимо) удалять из БД. Другой вопрос "когда и как"... можно и логически, можно и путем добавления признака "активная запись", можно и путем переноса в архивное хранилище, можно и ... конкретное применение - сильно зависит от задачи.

И, советовать всегда и везде "данные не удаляются из БД" - это и есть пример копропроекта. Да и правда, чего "париться"? Объемы хранилищ и не такое дерьмо хранить позволяют... нафига заботится о чистоте ещё на стадии проектирования?!?

Это и есть говноподход, насаждаемый всё активней. От неумения работать с данными.

guest_20040621> Флудить , троллить переходя на личности - это весь арсенал ваших аргументов, нет?

Дружище, вы категорически неправильно интерпретируете то, что вам пишут. Представьте, что второклассник с видом невероятного превосходства рассказывает студенту института о преимуществах таблицы умножения. Примерьте к себе образ второклассника, аналогия достаточно точная. Я даже не знаю, как реагировать на ваши ответы. Ваши представления о проектировании реально на уровне начала массового производства компьютеров. Вы на самом деле боретесь за право оставаться невежественным. Да нет проблем, если хотите - сколько угодно. Только апломба чуть меньше - и наслаждайтесь обсуждениями с ЧАЛом и им подобными.

Вам таки хочется потроллить... ок.

Предварительно на следующий пост:
Это из вашего поста: "Заказы - таблица, не связанная с продуктами. Отдельная таблица для связи заказа с продуктами."
(по картинке автора, как раз связана)... часть вашего ответа автору на вопрос "Очень сомневаюсь что правильно..."

... я читать не умею или Вы смотреть, дружище? :)

А теперь, по поводу перепалки, уважаемый "студент":
1. Моё сообщение было о копировании товара в заказ.
2. Ваш пост "о посмеяться" (как видим поперек моего поста) даже без пояснений... или лениво, или их просто нету... фиг знает.
3. Моё пояснение, основной частью которого было "не удаляем, от неумения работать с данными".
4. Ваш ответ о мировоззрении (опять же поперек поста) с вкраплениями не относящихся к вопросу деталей. Но без объяснений почто неудаляем, заметьте...
5. Мой ответ о нежелательности писать поперек...
6. и теперь Вы мне рассказываете о таблице умножения...

Доучитесь в своем институте уже, и приходите - пообщаемся, уважаемый студент.

P.S. Это наша с Вами третья перепалка, и она опять инициирована с вашей стороны, и опять с желанием оскорбить, без какого-либо полезного обсуждения... так кто из нас "второклассник"? :)

P.P.S. Ещё раз: если нет аргументов - не надо троллить в теме. Давайте обсуждать по-существу.

softwarerArhat109, ни Вы, ни Ваш оппонент не попали точно в истину, но Вы неизмеримо дальше от неё.


softwarerИспользуя Ваши термины, скажу так: данные в БД (некие конкретные записи) в подавляющем большинстве случаев входят в состав других, более сложных объектов, и, соответственно, не должны удаляться (подвергаться "сборке мусора") отдельно от этих объемлющих объектов. Объемлющие объекты в свою очередь входят в чей-то состав и в итоге практически всегда попадают в очень большой объект, скажем, "данные продаж за 2012-й год". Когда и как такой объект будет удалён и позволит "почистить мусор"... зависит от бизнес-процесса, конечно, но уже давно довольно очевидно, что данные гораздо ценнее, нежели место на архивных и не очень архивных носителях.

Да,да... именно такой копроподход и активно внедряется последнее время. Его вариант реального применения:
Есть списки данных, составляемые руководством для проработки сотрудниками... как правило составляются разово, как текущая задача. Требуется отчет "кому сколько назначено" (дабы грузить как положено)... решение:
Делаем выборку из списков на лету суммируя и вычисляя соответствующие показатели... всё "как надо"... на практике оказывается (99% содержимого - отработанный мусор), что запрос по отчету "летает" аж по 8 минут (соединение ограничено 60сек.), сажает сервак с 4-я ядрами на 500% да так, что никто ничего из БД выбрать не может ваще
... вместо того, чтобы ещё при создании списка, делать интегральные вычисления по нему, с корректировкой "на лету" (редактирование списка)... "блин, это же сложно! А вдруг оно не так посчитает?"

Смотрите ответ нашего "студента" - он верен: "это требует другой квалификации".

softwarer Также довольно очевидно, что бизнес-логика склонна меняться и развиваться, и может оказаться так, что данные, которые вчера удалены как ненужные, сегодня оказались нужны.

Для этого существует логическое (и физическое из рабочий части БД) удаление с переносом в "архивные структуры". Дампы, опять же никто не отменял, вроде как (на самый крайний случай)... или о них тоже уже давно забыли на передовых роспилах?

softwarer В результате этого Ваша позиция начинает напоминать, например, искусство упаковки данных в битовые структуры - да, в некоторых случаях нужно и сегодня, но попытка объявить его глобально необходимым вызовет здоровый и обоснованный смех.
Глобально необходимым - никто ничего не объявлял... найдёте - покажите. Пока наоборот, оппоненты тут пытаются какие-то постулаты объявить глобальными...
Специально оставил без комментариев первую часть... ну и? Здоровый и обоснованный смех, в данном случае, я так понимаю вызывает желание писать правильный, компактный код вместо говнокодерства (которое УЖЕ возведено в ранг "так надо"), нет?

Тогда, что смешного?

[quot guest_20040621Дружище, я потратил лет пять на то, чтобы в этом форуме не было обсуждений про естественные ключи. Получилось. До вас я был уверен, что и обсуждений по поводу истории изменений больше не будет. Мне не интересно сто раз писать одно и то же разным людям. Хотите - ищите самостоятельно, не хотите - живите обкуренным китайским первоклассником. В последнем случае воздержитесь от комментариев и ответов на не адресованные персонально вам вопросы.[/quot]

Дружище, потратьте ещё лет пять и доучитесь уже в своём институте, предварительно закончив школу. Прежде чем писать.

NetObserver,

первый вменяемый пост.

Всё верно, с точки зрения проблемы мусора в БД. Соглашусь.

Я написал первый пост несколько из других соображений, а именно из необходимости абстрагировать заказ от других сущностей в БД. Не вижу принципиальной разницы между "названием" и "ценой" товара. И то и другое - суть атрибуты, имеющие свойство меняться со временем (например исправление опечаток в названии или сознательное отстраивание от названия конкурента - видел и такое).

Почему тогда копирование цены в заказ - не вызывает вопросов, по сравнению с названием?

Банально: нет копирования, есть только ссылка на каталог. Что имеем:
состояние 1: выписка заказа по первоначальному названию. Отправка заказа клиенту.
состояние 2: изменение названия. -> автоизменение содержимого заказа на новое название (проблема таже что и с ценой!)...
состояние 3,4: отгрузка товара по новому названию и отправка накладной с новым товаром

... в итоге получаем рекламацию: пересортица при поставке!

и вот на такую пересортицу я в своей практике - реально натыкался!
строка заказа (за точность номера железки не ручаюсь):
HUB 3COM-15712-ME 10шт.

строка счет-фактуры и накладной на следующий день (это реальная ситуация)

SWITCH 3COM-15712-ME 10шт.

реакция получателя (почта, наложенный платеж, оплата доставки продавцом): это не тот товар, который был закуплен. Верните продавцу обратно.

... и попробуйте доказать клиенту, что он теперь должен оплатить двойную доставку, поскольку отказ по его вине (это же тотже товар, только переименован!)... :)

ViPRos,

ну да... именно на это наименование именно этого товару... :)

alexeyvgВыглядит абсурдом. Какое то автоизменение цены, названия :-)
Первый пост ТС (флудерасты постарались уже и тут): в таблице заказов хранятся идентификаторы купленных товаров

... и только. К чему ЭТО может привести - показал на примере, который вы раздербанили на две части... зачем-то. Это простое следствие хранения ссылки в заказе вместо наименования товара. Один документ печатается (отправляется) ДО изменения, а другой ПОСЛЕ... тока и всего.

alexeyvgНезависимо от того, изменилось название товара или нет, отгружен будет именно тот товар, который привязан к заказу. Не по названиям же кладовщик отгружает :-)

... Вы точно так уверены?!? Ещё и не так "отгружают"... бегает иной кладовщик по складу с бымажкой и крыжит чего он в коробку поскидал... и понять не может хде теперь этот switch искать надо. На складе одни только hub-ы. А то ещё и просто громко так орет в офис: "Вася, эт чего такое? Скока?"....

alexeyvgСохранение каталожной цены товара в момент продажи может быть полезно для неких статистических расчётов, но к самим бизнес-процессам не имеет ровно никакого отношения, так же, как и название товара.

Перенос каталожной цены в заказ происходит "сплошь и рядом" в любом интернет магазине не в момент "продажи", а в момент принятия покупателем оферты и создания в БД сущности "заказ". И вот ежели тут каталожное наименование не копируется, а в заказ втыкается тока ссылка на каталожное наименование - получаем ту самую пересортицу "автоматически". В момент выписки покупатель получит документ с одним наименованием, а в момент доставки - документы с другим. Или надо городить отдельный огород по учету, что с этим наименованием УЖЕ есть заказы а с этим ЕЩЁ нет... или огород с архивированием, "ведением истории", не удалением, не исправлением и т.д. (кто во что горазд из-за неумения работать с данными)

alexeyvgОба аттрибута товара - название и цена - для заказа и всех процессов совершенно бесполезны, не имеют ровно никакого значения.

интересный подход... и нафига их тогда вообще хранить?!? Да и проектировать чего-то... возьмите 1С, Галактику, бесплатную cms на бедность... этот раздел - можно и совсем закрыть... всё уже давно придумано и нормально спроектировано. И даже, неповерите - реализовано. :)

alexeyvgЭто не пересортица. Счёт-фактура или накладная - это не заказ, это отпечатанные документы, их понятно нужно сохранять полностью, само собой.

?!? Как клиенту доказываете что ЭТО не пересортица? В предварительном заказе (счете) - одно наименование, по факту поставки (в документах) - другое.

Да и, заодно, расскажите КАК вы будете печатать документы на отправку со старым наименованием (с которым заключен договор, выписан счет ранее и т.д.), если у Вас в БД только ссылка на каталожный товар, который ПЕРЕИМЕНОВАН? (смотрите первый пост)

Не, можно не заморачиваться (это же требует квалификации как тут уже написали). Просто запретить правку и удаление.
Ошибся? Поставщик переименовал позицию? Для сеошника так удобнее? Заведи ещё один товар, а этот отметь как неактивный... да и фиг с ним ... эт-та, мусором. :)