barsukoff
Сделать иерархию, чуть выше с каринкой я писал. Верхом иерархии будет Ваша сборка ,в таблице связи её (IDВернейДетали=0) по ней мы узнаем что это предел совершенства и выше искать не нада , в этой же таблице добавим поле ЗАКАЗ.

вы невнимательно читали топик. Иерархия и так есть, она у меня называется Входимостью. Содержит ссылку на детальСборку, детальПодсборку и количество.
softwarer
Почему в нескольких?

Если замена идет в одном месте, в одной сборке, значит update-им одну строку одной таблицы. Если замена идет в "нескольких из многих" - меняем несколько строк, скорее всего в одной таблице.
...
Про это. Возможно и есть, но в первом посте темы оно... как минимум не очевидно. Можно предположить, что у Вас IDСборки есть ссылка на таблицу деталей, если так, дерево становится видным, но это повод пересмотреть стандарты именования :)

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


В таблице Входимость IDСборки и IDДетали ссылаются на Детали.IDДетали, это и есть дерево изделия. Можно конечно было их назвать IDДеталиСборка и IDДеталиПодсборка но это не суть важно.
Что теперь происходит, если мы хотим создать новую детать и включить ее вместо старой ? Инсертим новую деталь. Запоминаем получившийся ее ID'шник. Идем во Входимость, и заменяем IDСтаройДетали на IDНовойДетали везде где она встречается. Потом идем в другие таблицы, содержащие ссылки на IDСтаройДетали и их тоже меняем. Таких "других" таблиц вообще говоря может быть много.
softwarer
Вот уж простите, не верю я в это. Не бывает так. В изделии и в какой-то его подсборке запросто может быть "четыре таких винтика и два вот таких", но вот чтобы шесть уникальных были типовым случаем.....
...
Не понял. Это "то есть" прямо противоречит предыдущей Вашей фразе. Если они уникальны, значит изменение касается только одного вхождения. Чтобы поменять все вхождения, надо много ссылок из сборки на один винтик.

нет нет, если винтик входит например в 50 сборок одного изделия, то во всех 50 сборках идет ссылка на один и то-же винтик. Про уникальность я тут похоже вообще неудачно выразился, он уникален в том смысле, что для конкретного изделия в таблице Детали винтик "ВИНТ В.М5-6ех14.48.С.029 Г.17475-80" имеет только одну запись, и все вхождения ссылаются на нее. Но это только для одного изделия. Если этот винтик входит в 2 изделия, то в таблице Детали будет уже 2 записи, но каждая для своего IDИзделия.
softwarer
Итак, непомнюкакому заводу были заказаны 20 самолетов Ту-4 - опытная партия. Сделали первые три, облетали, по первоначальным результатам решили сразу внести в остальные некоторые изменения. Имхо вполне обычная ситуация, которая должна закончиться тем, что в базе лежит заказ на три самолета конструкции 1 и на семнадцать самолетов конструкции 2. Далее, изменения, сами понимаете, были не очень велики, поэтому обе версии конструкции допустим, отличаются в 5% мест. Имхо вполне естественно иметь в базе 95% общего и дважды по 5% - различий.

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

А при чем тут собственно оператор ? Для него это будет выглядеть как окно, в котором он грубо говоря печатает старое и новое обозначение винтика, потом галками указывает изделия, где надо провести изменения и жмет ОК. Ему глубоко наплевать как там внутри это сработает.
Но мне-то не наплевать.
В случае вашего варианта, если винтик используется в нескольких изделиях, мы (как я уже писал) создаем новый винтик, и апдейтим все таблицы, которые имеют ссылки на старый винтик, заменяя их ссылками на новый (разумеется только для отмеченных изделий). Тут кстати возникнут интересные моменты, в частности, потребуется как-то различать к какому изделию относиться конкретная запись входимости (сейчас эта информация имеется в Детали.IDИзделия).
В моем варианте, апдейтим записи винтика для каждого изделия.

Не вижу очевидных преимуществ первого варианта.
softwarer
Это неудачная мысль, пожалуй не стоит ее обсуждать.

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

Не понял, а что значит "ввести принципиальную схему изделия" ? Ввести сначала все сборки что-ли ? Они-же не все известны сразу. Я-же говорю, оператор ввода входимости не знает, что карбюратор входит в двигатель. Что-ж ему теперь, запретить вводить структуру карбюратора, пока он не узнает про двигатель ? Так ведь и этого будет мало, двигатель тоже не напрямую к нулевой сборке автомобиля цепляется.
softwarer
Я перевел эту фразу ровно так же, как и Вы. Я сказал, что меня в ней не устраивает. Если Вы с этим не согласны - было бы разумно это обсудить. Вместо этого Вы полагаете, что я неправильно перевел. Подозреваю, связано с тем, что Вы придерживаетесь точки зрения "если бы перевел как я, то и думал бы как я".

Печально..... не вижу правда, почему в результате именно я в глупом положении, но давайте считать, что Вам виднее.

если-бы вы перевели эту фразу так-же как и я, то чушью-бы ее не обозвали. Ладно, закрыли тему
softwarer
С тем, что микрософт такую идею продвигает, Вы готовы согласиться?

Какую идею ? Возможность создания несложных БД с помощью дизайнера ?
softwarer
перешли на ориентацию на неграмотных программистов. Точнее, ту стратегию маркетинга, которую применили на пользователях, применили и на программистах. И снова сработало неплохо, популярности среди программистов добились.

"стратегия ориентации на неграмотных программистов". Было-бы неплохо подкрепить такие слова ссылками, а то это выглядит очередной "интепретацией" и "логическим выводом", за которые вы меня тут так критиковали
softwarer
Если посмотрите, увидите, что разницы в сложности никакой. Что же до лучше-хуже, вопрос в количестве применений. Для запроса, который в течение жизни системы применяется, например, 100.000 раз, требования к оптимальности одни; для запроса, который выполняется, например, 40.000.000 раз в неделю, требования к оптимальности другие.

ну хорошо, если даже и нет разницы в сложности. И что собственно из этого следует-то ? Стратегия ориентации на неграмотных программистов ?
softwarer
stenf, простите, знаете ли Вы Oracle достаточно, чтобы от своего имени критиковать его за излишнюю сложность? Если так - если хотите, давайте создадим отдельный топик в "Сравнении СУБД" и поговорим. Если нет - простите, но говорить со "слышал звон" бессмысленно. Вы взяли одно сомнительное утверждение, и не глядя на пример, развили из него теорию "что в этом примере находится".

нет я не знаю Оракл, и от своего имени я его и не критиковал. Я сказал "критикуют". Что-бы убедиться в наличии этой критики, не надо знать Оракл. А раз критикуют, то не все здесь так просто, дыма без огня не существует.
softwarer
А вот ситуация "сервер не дает применить эффективное решение, поскольку решает за меня слишком грубо" меня, если честно, напрягает и эффективным я такой подход не считаю.

Вообще согласен, оптимальный подход - некое автоматизированное действие по умолчанию с возможностью изменить поведение по-желанию. Но в каждом случае надо смотреть по ситуации, я допускаю наличие случаев, в которых ничего вы руками не сделаете
softwarer
Код, понятный Вам, будет непонятен человеку, позавчера впервые открывшему учебник по программированию. А код, понятный тому, не будет понятен пятилетнему ребенку. Говоря "писать понятный код" Вы на самом деле не говорите ровно ничего, бросаете бессмысленный лозунг, поскольку не даете ответа на ключевой вопрос - "понятный для кого".

Для любой задачи, для любой команды, есть некий оптимальный минимальный уровень ее членов, равно как и оптимальный максимальный. Есть задачи, куда просто нельзя привлекать студентов, есть задачи, куда однозначно не следует привлекать гуру. Код должен быть понятен членам команды. Говорить "код хорош только если его без малейших усилий поймет каждый придурок" - неоптимально с точки зрения решаемой задачи. Далее, писать "слишком сложный код" безусловно плохо. В то же самое время команде полезно, если ее члены подтягивают свой уровень, члены "минимально допустимого уровня" должны быть временным явлением.

а причем тут пятилетние дети ? Да, код должен быть понятен членам команды. Понятность - никакой не лозунг, а здравый совет.
softwarer
Пример хорошего, правильного подхода: вопрос, ответ, результат. Хотя я почему-то подозреваю, что Вы этот пример не воспримете.

я тоже например не знаю того хитрого оператора. И что с того ? (если позволите, то гуглить не полезу, поздно сейчас, на выходных возможно)
softwarer
Вы забываете про одну мелкую, но важную деталь: "относительная сложность кода" - вещь субъективная.
...
Скажете, этот код сложнее? Нет, ему так было проще. if - более простое понятие, чем например "массив".

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

вы немного смешиваете понятия. Дело не в том, что массив сложнее, чем if. Дело в том, что некоторые подходы усложняют код в не зависимости от ваших познаний (я уж не говорю о таких случаях, как глубокая вложенность if-else'ов например, очевидно тут надо не людей нанимать, способных разобраться в n-уровневой вложенности, а упростить код). Например рекурсия. Может быть полезна в некоторых случаях. Однако вообще она усложняет понимание в не зависимости от того, как хорошо вы в ней разбираетесь. Есть даже такой известный пример, когда рекурсию лучше заменить итерацией - вычисление факториала.
softwarer
Неправильное значение может появиться из-за неверного where в update. Неправильная строка может появиться из-за неправильного on в merge или where в insert..select. В чем разница?
...
Я не очень понимаю, с какой стати я замучаюсь писать и сопровождать check-и, если это забота CASE-средства. Моя забота - нарисовать дугу в ER-диаграмме. Впрочем, даже если и надо будет писать руками - .... Вы всерьез полагаете, что аргумент "замучаешься писать foreign key-и" достаточен, чтобы не делать в БД никаких foreign key-ев? А ведь ситуация та же.

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

Если разрешите, задам вопрос такой вопрос: правильно-ли я вас понял, что при разработке схемы БД вы ориентируетесь на такие параметры как количество обьектов БД, кол-во чеков и пр. для обеспечения бизнес-правил, а получаются-ли в результате nullable поля - не обращаете внимания ?

ModelR
Вы действительно перевыпускаете спецификацию и все чертежи входящих деталей на некую сборку СБ12345, если примените ее (без каких-либо изменений) в другом изделии ???

нет, а с чего вы взяли ?