vadiminfoБредятина Разумеется эпоха РМД на дворе, и я это ясно подтвердил
Наконец-то до Вас дошло это через 30 лет.
МУМПС здесь подбрасывали вместо РМД. Мешочки, Дореляционную ОМД, объектный нафигатор. Смешно просто вспоминать. Теперь, надеюсь, взялись за ум.
Помимо серьезных технических ошибок, Вы (когда обижаетесь на свое незнание) все время еще и врете)))
))) Вот мой текст:
1) Приложение "видит" совсем другую структуру, имеет дело с другими ОЦ и написано на другом языке. Поскольку не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" то - перманентное программирование. И это (обеспечение программистов работой на всю жизнь) вполне можно отнести к достоинствам реляционной технологии.
2) Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".

Вы допускаете серьезные ошибки, когда пишете что-то про БД) И когда я Вам на них указываю, обижаетесь, и начинаете писать не по существу) Нечего сказать по существу, так не пишите здесь сообщения... Разумеется эпоха РМД на дворе, и я это ясно подтвердил)))

vadiminfoПросто до Вас не доходит, что Вам пишут. Надо было получать нормальное образование.
))) Врунишка. Вынудил я Вас говорить по существу. И вот традиционное вступление. По отношению к человеку, который понимает лучше других технологию БД)) Это нормальная реакция людей, которые обижаются на свое незнание.
vadiminfoНе знаю зачем Вы повторяете эту галиматью (включате попугая). В РМД все легче чем где-либо, раз реляционная эпоха. А Вы ея признали.
Пока продолжаете лгать, и ставите себя уже в совершенно глупое положение, так как потом начинаете-таки реагировать на "галиматью" на уровне своих знаний технологии БД)))
Вот мой текст:
1) Приложение "видит" совсем другую структуру, имеет дело с другими ОЦ и написано на другом языке. Поскольку не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" то - перманентное программирование. И это (обеспечение программистов работой на всю жизнь) вполне можно отнести к достоинствам реляционной технологии.
2) Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".

Вы допускаете серьезные ошибки, когда пишете что-то про БД) И когда я Вам на них указываю, обижаетесь, и начинаете писать не по существу) Нечего сказать по существу, так не пишите здесь сообщения... Разумеется эпоха РМД на дворе, и я это ясно подтвердил)))
Здесь только факты. А для многих "любителей" реляционной технологии факты - это галиматья) Это я помню.
vadiminfoПриложение видит не какую-то "совсем другую структуру", а представление данных БД. Представления об информации в РМД - просто сохраненные запросы на том же языке SQL.
Вы в начале пути понимания реляционной технологии)
vadiminfoПроще некуда. Неужели это так трудно доходит? Хоть Вы и далекий от проектирования БД человек (Вы больше по мешочкам специалист), но все равно могли сообразить уже.
Очевидная глупость) Если бы все было "проще некуда", то приложение не нужнО (при использовании СУБД именно так и происходит - приложения не нужно программировать).
Поскольку при использовании реляционной технологии не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" то остается одно - перманентное программирование приложений. И это большая заслуга реляционной технологии для современного "мира отмывания денег")))
vadiminfoДумаете, что если удалить таблицу, то нельзя изменить представление так чтобы оно возвращало те же колонки, что и до удаления?
Типа разоблачили Кодда? 9 правило? Так просто? А все человечество до Вас не додумалось? Рассел просто нервно курит со своим парадоксом.
Продолжаете игнорировать мой текст и заменяете его ответом на свой собственный вопрос) Вам нужно чиновником работать))) Вот мой текст:
Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".

vadiminfoБредятина Вот мой текст:
Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".
А я на этот текст и отвечал. Хотя и без ответов очевидно, что таким наивом Кодда могли пытаться критиковать тока начиающие. Тока до Вас доходит.
Банальная неправда) Как обычно.
Вот Ваш текст (дополненный и исправленный Вами):

"Если приложение видит представления, а не таблицы, то код приложений трогать не придется, только изменить представления."

Это ошибка, конечно же, и я на нее указал:

Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".
vadiminfoВаш пример мог опровергать независимость с помощью механизма представлений только, если бы не существовало таких изменений БД, при которых не нужно менять код приложения.
Опять неправда) В Вашем тексте нет слов "в ряде случаев" или других подобных. Вот Ваш текст:

"Если приложение видит представления, а не таблицы, то код приложений трогать не придется, только изменить представления."

Попутно замечу, что при использовании СУБД, в отличие от реляционных СХОД, код приложения дейстивительно не нужно изменять ни при каких измененниях в схеме БД, просто потому, что приложения просто не нужно программировать))
vadiminfoТ.е. либо требуемая инфа есть после удаления В, тогда можно изменить запрос представления. Если ее нет, то добавление оной есть изменение БД, а не кода приложения.
))))) Итак, Вы продолжаете утверждать, что код, например, умножающий A на B, не придется трогать после, например, удаления B из таблицы и из представления, . Вы дополняете этот простой пример своим собственным примером, в котором атрибут B после удаления непременно должен быть снова добавлен в какую-либо таблицу. Я и говорю, Вам чиновником нужно работать))

vadiminfoЧал пытается подбросить новенькое обоснование "бесполезности РМД".
Умышленная неправда. Обоснование сделано давно и детально (ссылки известны всем заинтересованным) и опровергнуть его просто невозможно.
vadiminfoНо если последние годы он пытался преувеличивать и по своему истолковывать известные в литературе недостатки, то теперь он пытается как-то отюзать для этого известные достоинства оной. Т.е. как бы возвращается на круге своя в период с 2004 до бана, когда стремился вызвать максимально возможное недоумение своими текстами.
Глупости из-за неспособности вести обсуждение по существу)))
Где преувеличение?)
Что означает "известные в литературе"?))) А на практике их как бы нет?
Какие достоинства? У реляционной технологии нет ни одного достоинства, присущего именно ей. Это факт, хорошо известный не только в литературе.
Надо банить ЧАЛа) Это тоже факт.
Какое недоумение?))
Вы о том, что мало кто знаком с технологией БД? Потому что большинство знакомо только с ее глубоко ошибочной и незначительной веткой - реляционной технологией? И поэтому факты технологии БД вызывают у большинства недоумение?))
Это не беда. Было бы желание разобраться в предмете.

vadiminfoБредятина... Вы продолжаете утверждать, что код, например, умножающий A на B, не придется трогать после, например, удаления B из таблицы и из представления, . ... атрибут ... добавлен в какую-либо таблицу.
А по Вашему изменение таблицы это изменение кода? Т.е. "Вы продолжаете утверждать, что" не смотря на то что "атрибут ... добавлен в какую-либо таблицу" придется еще и код менять?
))) Атрибут удален, а не добавлен. Вот мой текст:

))))) Итак, Вы продолжаете утверждать, что код, например, умножающий A на B, не придется трогать после, например, удаления B из таблицы и из представления,. Вы дополняете этот простой пример своим собственным примером, в котором атрибут B после удаления непременно должен быть снова добавлен в какую-либо таблицу. Я и говорю, Вам чиновником нужно работать))

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

vadiminfoБредятинаКакое недоумение?))


после которого мы с Вами пришли к вызывающему доверие выводу, что

БредятинаДо таких идиотов, как я, конечно, не доходит))

)))) То есть после удаления атрибута B из таблицы и представления Вы все равно будете в коде умножать A на B? Я так и знал))

vadiminfoБредятина))) Атрибут удален, а не добавлен..
А что БД не позволяет добавлять атрибуты? Раз код менять не надо, а только БД, то наличие механизма независимости на лицо.

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

))) Атрибут удален, а не добавлен. Вот мой текст:

))))) Итак, Вы продолжаете утверждать, что код, например, умножающий A на B, не придется трогать после, например, удаления B из таблицы и из представления,. Вы дополняете этот простой пример своим собственным примером, в котором атрибут B после удаления непременно должен быть снова добавлен в какую-либо таблицу. Я и говорю, Вам чиновником нужно работать))

Вы ведете себя просто не прилично) Я всегда точно цитирую оппонента, а Вы умышленно выдергиваете куски какие-то. Большинству читателей, конечно, безразлична теория и практика БД, и они не обратят внимание на Ваше умышленное нежелание писать по существу. Я пишу здесь сообщения, и детально рассматриваю каждый вопрос ради тех немногих участников форума, которые искренне хотят изучать технологию БД. Не пишите сообщения, если не хотите обсуждать по существу.
vadiminfoБредятинаТо есть после удаления атрибута B из таблицы и представления Вы все равно будете в коде умножать A на B?

Да я то вообще в представлении умножу, в коде тока селект из этого представления. Спасибо Кодду.
Умышленная глупость. В БД (и в таблице, и в представлении) B удален. А в коде осталось умножение на B. Вы что, даже не ощущаете как выглядите со стороны?))
vadiminfoС Вашим уровнем и доходчивостью, только о "теория и практика БД" у других беспокоиться.
)))) То есть после удаления атрибута B из таблицы и представления Вы все равно будете в коде умножать A на B? Я так и знал.

vadiminfoБредятинаВ БД (и в таблице, и в представлении) B удален. А в коде осталось умножение на B.
В БД добавли необходимую для клиента информацию и переписали представление так, чтобы в коде ничего не изменилось.
Изменения в БД? В БД. Код менять не надо? Не надо. Все. В этом одно из важных достоинств РМД.
Умышленная глупость. В БД (и в таблице, и в представлении) B удален. А в коде осталось умножение на B. Вы настойчиво предлагаете обратить внимание на фундаментальный недостаток реляционной технологии - невозможность изменить код приложения. И чтобы код (заметим, уже никому не нужный) продолжал работать необходимо:
1) снова добавить B в какую-нибудь таблицу БД (вероятно, Кодд рекумендует создать специальную таблицу для такого рода ненужных атрибутов))))
2) переписать код представления, чтобы в нем остался B;
3) переписать код интерфейса, чтобы результат умножения А на B нигде не отображался.
Не проще ли честно сказать: реляционная технология предполагает запрет на удаление атрибутов?))) И это одно из "важных достоинств РМД".
Приходится с юмором воспринимать Вашу настойчивую глупость. На самом деле перманентное изменение кода по любому поводу - это одно из важных "достоинств" РМД, дающее работу армии программистов) В случае использования СУБД приложение просто не нужно программировать.

Кот МатроскинБредятина В случае использования СУБД приложение просто не нужно программировать.
А что на B надо умножать (а не делить, скажем) - эта "СУБД Бредятины"(tm) сама догадается? Телепатически?
))) Примитивное смешивание. Речь ведь шла о приложениях, код которых, якобы, не изменяется. Очевидно, что если приложение есть, то его код должен быть изменен при определенных изменениях в схеме БД (и я привел тривиальный пример). Если приложения нет, то его код даже теоретически не может быть изменен)) Вероятно, Вы хотели сказать, что и в случае реляционной технологии можно обойтись без приложения (умножать A на B на уровне БД, а когда B удаляется - не умножать на уровне БД). Однако, семантическая бедность РМД не позволяет обойтись без приложения даже в простых случаях. Это просто факт.

LSVофф: Бредятина, Вы женаты ? Дети есть ? :)

Чисто интересно.
Вы настолько не образованы, что не знаете даже таких примитивных вещей???:)

vadiminfoБредятинаВы настойчиво предлагаете обратить внимание на фундаментальный недостаток реляционной технологии - невозможность изменить код приложения. И чтобы код (заметим, уже никому не нужный) продолжал работать необходимо:
1) снова добавить B в какую-нибудь таблицу БД ...
2) переписать код представления, чтобы в нем остался B;
.
Это до Вас наконец дошло, что может означать:
"В БД добавили необходимую для клиента информацию и переписали представление"?

Да Вы просто на лету схватываете.
Вам что, действительно не стыдно?)) Люди же некоторые читают)) Вы что всерьез восприняли эту "рекомендацию Кодда"?)))
То есть, получается, что Вы идиот? Я в это не верю, честно говоря. Убежден, что Вы нормальный непорядочный человек)
vadiminfoБредятина3) переписать код интерфейса, чтобы результат умножения А на B нигде не отображался.

зачем же Вы делали пп 1 , 2 если, оказывается, было нужно чтобы "результат умножения А на B нигде не отображался"?
Да уж, тот еще тЭортик.
Не мы, а Вы)) Вы уже просто не знаете, как выйти из положения, и вместо того, чтобы признать, что код приложения меняется при определенных изменениях в схеме БД, продолжаете откровенно глупить))
vadiminfoВ конце концов, можно было тока пп 2 выполнить, чтобы нули отображались, чтобы код не менять.
Все равно Ваши проекты, судя по всему, времен СМ-4.
Глупышка)) Ни в таблице, ни в представлении нет В, какой еще п. 2) без п. 1)?)))
vadiminfoБредятина На самом деле перманентное изменение кода по любому поводу - это одно из важных "достоинств" РМД, .
9 правило Вам разжевать, скорее всего, не возможно.
Вы просто хам, это Вы уже хорошо здесь всем разжевали))

LSVБредятинапропущено...
Вы настолько не образованы, что не знаете даже таких примитивных вещей???:)Простите, но соотв.статьи в Википедии не нашел. Может подскажете ?
Хочу составить психологический портрет акцентуированной личности.
Не ожидал, что Вы так легко дадите утвердительный ответ) В сочетании с тем, что технология БД Вам не интересна, это даже не знаю как называется в психологии))
А Вашу идею про ключи я оценил.