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]

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