Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 95 96 97 98 99 [100] 101 102 103 104 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Мыш Летучий
а на деле вы так и не смогли мне толком объяснить
как в РБД реализовать наследование и ассоциацию без дополнительных таблиц и связей.
И не объясните никогда, потому что НИКАК.
Аналогичные по бессмысленности вопросы: как в программе записать присваивание вообще без использования оператора присваивания? Как в ООП организовать наследование без единого объявления одного класса наследником другого класса?
Короче, как в некоторой формальной системе сделать что-то, вообще не используя средства и механизмы этой системы? Правильно, НИКАК. Идиотизм какой-то.
Мыш Летучий
А если даже в Оракуле появились вложенные таблицы и объекты,
значит "чистая" реляционная модель данных уже не катит и теория идет немного в топку?
Позвольте вас немного макнуть личиком в лужицу. Наличие вложенных отношения и поддержка пользовательских типов любой сложности не противоречит РМД. Более того, является одной из магистральных линий развития реляционных систем. Об этом, скажем, очень много написал нелюбимый вам Крис Дейт (см. 7 и 8 изд. Введения в системы БД и 3 Манифест).

А про impedance mistmatch и прямое хранение объектной структуры программы в БД добавлю свои пять копеек. Если для вашей БД у вас предусмотрена одна единственная, не изменяющаяся программа, то таки да, хранить ее объектную модель имеет смысл. Но такие системы -- несерьезный уровень.

Взять MES-систему газодобывающего предприятия. Ее пользователи весьма разнородны -- геологи, диспетчеры, механики, энергетики, АСУшники, метрологи и т.д. (список длинный). Каждому пользователю нужен свой кусок базы, свой вариант клиенского интерфейса, свои формы ввода и отчетности. Причем одни и те же данных каждому типу пользователей нужны в своем разрезе, в своей иерархии представления.

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

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

Выбор ООСУБД с ориентацией на объектную модель одного клиентского приложения -- гибелен.
20 янв 07, 10:42    [3670033]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Л
Guest
mir
Вопрос: чья объектная модель клиентского приложения является единственно верной и должна лежать в БД
Позвольте, и я вас макну)))
Я вам про объектную модель предметной области, а вы мне про объектную модель кнопочек клиентского приложения.
А серверное приложение с ЕГО объектной моделью у вас отменили?
Клиенты лезут прямичком в базу, а общую логику в каждом клиенте копируем через буфер обмена, да?
знаем, проходили такое..

Господа адвокаты РБД!
Я ж пока еще тока думаю, надо оно пост-РБД или все-таки не надо.
А ваши доводы типа "покайся" и "наша теория правильная, потому что она верная", "ООП это вообще плохо"
убеждают только наборот, поскорее уйти из этого странного "мира БД",
где "очевидно" что руки должны храниться отдельно от ног..
20 янв 07, 11:41    [3670070]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Л
Guest
mir
Мыш Летучий
а на деле вы так и не смогли мне толком объяснить
как в РБД реализовать наследование и ассоциацию без дополнительных таблиц и связей.
И не объясните никогда, потому что НИКАК.
Аналогичные по бессмысленности вопросы: как в программе записать присваивание вообще без использования оператора присваивания? Как в ООП организовать наследование без единого объявления одного класса наследником другого класса?
Короче, как в некоторой формальной системе сделать что-то, вообще не используя средства и механизмы этой системы? Правильно, НИКАК. Идиотизм какой-то.

Ура, наконец-то! Значит сущности из РБД не переносятся автоматически в область объектов серверного приложения и надо делать это ручками?
(представляете, мне тут доказывали обратное)

А если появляется концепция, где понятия РБД и ООП увязаны однозначно
(путем обработки напильником того и другого)
то почему она обязательно "плохая" и "сатанинская"
и надо сразу хвататься за валидол и икону св. Кодда?
20 янв 07, 11:48    [3670083]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Л
Guest
mir
Мыш Летучий
А если даже в Оракуле появились вложенные таблицы и объекты,
значит "чистая" реляционная модель данных уже не катит и теория идет немного в топку?
Позвольте вас немного макнуть личиком в лужицу. Наличие вложенных отношения и поддержка пользовательских типов любой сложности не противоречит РМД. Более того, является одной из магистральных линий развития реляционных систем. Об этом, скажем, очень много написал нелюбимый вам Крис Дейт (см. 7 и 8 изд. Введения в системы БД и 3 Манифест).

Почему вдруг нелюбимый?!? Как и физика Ньютона, теория РСУБД - хорошее и удобное приближение.
Только знаете, куда нас приводит "магистральная линия вложенных отношений и поддержки пользовательских типов любой сложности"?
Правильно, к изобретению многомерных массивов как оптимальной структуры хранения наших [уже] многомерных данных.
А если вдруг потребуется прямой доступ к этому хранилищу (ну для оптимизации загрузки скажем) - ничего страшного, мы изобретем М.

Тужтесь.. осталось немного и вы родите пост-РБД.. (или подождем пока ее родят теоретики?)
20 янв 07, 12:31    [3670126]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Мыш Летучий
А спросишь, как вы наследование или аггрегацию делаете -
Ребят, о чем спорим-то? ;)
У каждого продукта - свои области применения. Там, где по-барабану скорость работы, а важна скорость и удобство РАЗРАБОТКИ, можно применять Кашу, где нужно обеспечение производительности и надежности, а на удобство разработки можно забить - вэлкам ту Скуль Ворлд. И вопрос не в сравнении ООП vs RDB, а в том, насколько существующие инструменты позволяют решить конкретную задачу.

По поставленному вопросу - а кто сказал, что наследование вот прямо так нужно реализовывать в БД? А? Я ни разу таких требований от заказчика не слышал. Мне, наверное, не везло с заказчиками, но самый грамотный из них вообще слабо себе представлял, что такое - "клиент-сервер". И буду я применять ООП или нет - ему, как ни странно, глубоко фиолетово.
И до сего дня РМ мне хватало для реализации самых сложных задач.
Конечно, есть моменты, когда наследование так и напрашивается сделать именно в БД - например ситуация, когда заказчиком может быть юридическое или физическое лицо и у каждого свой набор аттрибутов. Сразу хочется создать класс Person, наследовать от него классы LegalEntity & SingleMan и к таблице заказов привязывать наследников класса Person. Но на самом деле, способы решения этой "проблемы" есть. И то, что они, возможно, не так "изящны", как "чистое ООП" - не сильно и смущает. Зато не приходится мучатся с выбором способа доступа к данным - насколько я понимаю, в Cache в зависимости от необходимости нужно изобретать либо собственные механизмы (те же блокировки), либо обращаться к методам, далеким от ООП (когда речь заходит о производительности). C++ стал "прогрессивнее" ассемблера только тогда, когда появились более-менее быстрые компьютеры. А системы массовой обработки данных такой роскоши нам пока не предоставляют - иногда повысить мощность БД закупкой нового оборудования просто невозможно - ну нет процессоров на 10гигагерц и 128-процессорных систем, на которых смогут работать "коробочные" СУБД.

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

Как-то взгрустнулось - написал пятнашки на MSSQL - только применяя DML-операторы (SELECT, INSERT, UPDATE). 3 процедуры (от 5 до 15 строк каждая) и одна табличка из 2-х полей. Вввод-вывод - при помощи ЛЮБОГО SQL-клиента. То есть задача была решена относительно "оптимальным" способом - в написанной на Pascal-e в свое время программе текст был в десятки раз длинее.
20 янв 07, 14:19    [3670311]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Мыш Л
Тужтесь.. осталось немного и вы родите пост-РБД.. (или подождем пока ее родят теоретики?)
:) Скорее - нет. Однажды появится продукт, в котором можно будет решить проблемы типа "наследования" или "как же заставить это наследование не так сильно тормозить" без отхода от "основной линии партии". У кого он появится - в лагере ОО или РМ - даже не так и принципиально. Только я писал выше - для того, чтобы он появился недостаточно просто его изобрести - нужно еще и дождаться, когда появятся способные его хоть как-то "обрабатывать" компьютеры. 20 лет назад производительности никакого компьютера не хватило бы для реализацции SNAPSHOT изоляции для десятка пользователей на одной машине.

Кстати, никто не тужится - реализуют наследование в очередной версии MSSQL - парадуюсь, не реализуют - да и ладно, не в наследовании радость.
К тому же, разве в ООСУБД данные не хранятся так или иначе в виде списков типизированных данных? Разница только в синтаксисе доступа к этим данным. И что теперь, будем, как болельщики Спартака и ЦСКА друг друга "лупить" за приверженность SELECT? особенно учитывая, что в РСУБД применяют все-таки наследование в том или ином виде, а Кашисты не гнушаются забить на ООП - методы и поковыряться в данных практически "руками"? ;)
20 янв 07, 14:30    [3670326]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
DeColo®es
Там, где по-барабану скорость работы, а важна скорость и удобство РАЗРАБОТКИ, можно применять Кашу, где нужно обеспечение производительности и надежности, а на удобство разработки можно забить - вэлкам ту Скуль Ворлд.
Это кто ж Вам сказал, что Cache не обеспечивает скорость работы? :)
20 янв 07, 14:49    [3670350]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Sergei Obrastsov
DeColo®es
Там, где по-барабану скорость работы, а важна скорость и удобство РАЗРАБОТКИ, можно применять Кашу, где нужно обеспечение производительности и надежности, а на удобство разработки можно забить - вэлкам ту Скуль Ворлд.
Это кто ж Вам сказал, что Cache не обеспечивает скорость работы? :)
Насколько я знаю, для обеспечения этой скорости нужно отойти от принципов ООП и другие методы обращения к данным.
20 янв 07, 15:08    [3670387]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
в предыдущем посте после "ООП и" добавить "использовать" ;)
20 янв 07, 15:12    [3670396]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Л
Guest
да-да, и раскладываете ноги в отдну таблицу, а руки в другую
вы тоже в интересах производительности?
чтобы потом "быстро" их оттуда вынимать при помощи JOINов..
что-то не очень нескладывается.
20 янв 07, 15:37    [3670431]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Л
Guest
DeColo®es
[quot Мыш Летучий]а кто сказал, что наследование вот прямо так нужно реализовывать в БД? А?
канешь, намного эффективнее, оптимальнее и (главное!) теоретически обоснованее
будет все маломальски похожие сущности засунуть в одну таблицу с кучей полей,
половина из которых будут всегда пустыми.
как там эта "концепция" называется у Кодда?
20 янв 07, 15:42    [3670437]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
DeColo®es
Sergei Obrastsov
DeColo®es
Там, где по-барабану скорость работы, а важна скорость и удобство РАЗРАБОТКИ, можно применять Кашу, где нужно обеспечение производительности и надежности, а на удобство разработки можно забить - вэлкам ту Скуль Ворлд.
Это кто ж Вам сказал, что Cache не обеспечивает скорость работы? :)
Насколько я знаю, для обеспечения этой скорости нужно отойти от принципов ООП и другие методы обращения к данным.

У Вас есть какие-то конкретные претензии к реализации ООП в Cache в связи со скоростью работы?
Или Вы делаете вывод из намеков на "тормозную" эмуляцию SQL в ней? Ну так они никак вообще-то не связаны.
20 янв 07, 15:46    [3670441]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Л
Guest
DeColo®es
Sergei Obrastsov
DeColo®es
Там, где по-барабану скорость работы, а важна скорость и удобство РАЗРАБОТКИ, можно применять Кашу, где нужно обеспечение производительности и надежности, а на удобство разработки можно забить - вэлкам ту Скуль Ворлд.
Это кто ж Вам сказал, что Cache не обеспечивает скорость работы? :)
Насколько я знаю, для обеспечения этой скорости нужно отойти от принципов ООП и другие методы обращения к данным.
вот именно, там где нужно крутая логика надо использовать объектный доступ.
там где нужна скорость запросов - сиквел доступ.
там где быстрая загрузка - прямой.

а в "вэлкам ту Скуль Ворлд" есть возможность такого выбора?
20 янв 07, 15:51    [3670444]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Sergei Obrastsov
Или Вы делаете вывод из намеков на "тормозную" эмуляцию SQL в ней? Ну так они никак вообще-то не связаны.
Эти "выводы" сделали коллеги, работающие на Каше.
Причем не пивной ларек они автоматизировали. :)
20 янв 07, 20:25    [3670789]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Мыш Л
как там эта "концепция" называется у Кодда?
А фиг знает. Я ТАК не делаю. :)
А как это называется "внутри" Cache? Ведь нужно же знать, как "это" организовано, чтобы пользоваться "прямым доступом"... Мне правдо не очень понятно, зачем пользоваться продуктом, в котором приходится знать несколько "неполноценных" технологий (потому, что "крутого ООП", как оказывается, недостаточно, блокировки - руками и т.д.), когда можно пользорваться продуктом, в котором одна технология реализована так, что другими пользоваться даже в голову не приходит. Ну не нужно в T-SQL более прямого доступа к данным, чем SELECT.

ЗЫ Я не желаю "клеймить" Кашу почем зря. Нравится - пользуйтесь... Но "отстаивать" ООСУБД только потому, что "ООП круче", а не потому, что они "быстрее", "надежнее", "удобнее" - как-то неконструктивно.
20 янв 07, 20:32    [3670793]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мыш Летучий
Member

Откуда:
Сообщений: 47
DeColo®es
ЗЫ Я не желаю "клеймить" Кашу почем зря. Нравится - пользуйтесь... Но "отстаивать" ООСУБД только потому, что "ООП круче", а не потому, что они "быстрее", "надежнее", "удобнее" - как-то неконструктивно.
Мне лично Каша нравится
потому что в ней не надо отделять серверное приложение от базы, а логику от данных,
во всяком случае мне так "удобнее".
20 янв 07, 21:33    [3670846]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
DeColo®es
Sergei Obrastsov
DeColo®es
Там, где по-барабану скорость работы, а важна скорость и удобство РАЗРАБОТКИ, можно применять Кашу, где нужно обеспечение производительности и надежности, а на удобство разработки можно забить - вэлкам ту Скуль Ворлд.
Это кто ж Вам сказал, что Cache не обеспечивает скорость работы? :)
Насколько я знаю, для обеспечения этой скорости нужно отойти от принципов ООП и другие методы обращения к данным.


да надо отойти
но зато (на CACHE 5.2 )
15 секунд весь расчет зарплаты на завод 2800 чел
с налогами удержаниями и глубокими перерасчетами

кстати что за пятнашки - давайте условие - мы тоже порешаем на м
ради спортивного интереса

<< а на удобство разработки можно забить - вэлкам ту Скуль Ворлд.>>
честно говоря не предполагал , читая данную дискуссию ,
что разрабатывать на SQL неудобно
21 янв 07, 00:45    [3671039]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
DeColo®es
Sergei Obrastsov
Или Вы делаете вывод из намеков на "тормозную" эмуляцию SQL в ней? Ну так они никак вообще-то не связаны.
Эти "выводы" сделали коллеги, работающие на Каше.
Причем не пивной ларек они автоматизировали. :)
Я так и понял. Очень ценная информация.
21 янв 07, 01:14    [3671078]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
Решил немного почитать теорию БД. По-моему это шедевр.
-------------------------------------------------------------------

Оператор деления

Реляционная алгебра: A(X,Y) DEVIDE BY B(Y)

Оператор SQL:

SELECT DISTINCT A.X
FROM A
WHERE NOT EXIST
(SELECT *
FROM B
WHERE NOT EXIST
(SELECT *
FROM A A1
WHERE
A1.X = A.X AND
A1.Y = B.Y));

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

Пусть отношение A содержит данные о поставках деталей, отношение B содержит список всех деталей, которые могут поставляться. Атрибут X является номером поставщика, атрибут Y является номером детали.

Разделить отношение A на отношение B означает в данном примере "отобрать номера поставщиков, которые поставляют все детали".

Преобразуем текст выражения:

"Отобрать номера поставщиков, которые поставляют все детали" эквивалентно

"Отобрать те номера поставщиков из таблицы A, для которых не существует непоставляемых деталей в таблице B" эквивалентно

"Отобрать те номера поставщиков из таблицы A, для которых не существует тех номеров деталей из таблицы B, которые не поставляются этим поставщиком" эквивалентно

"Отобрать те номера поставщиков из таблицы A, для которых не существует тех номеров деталей из таблицы B, для которых не существует записей о поставках в таблице A для этого поставщика и этой детали".

Последнее выражение дословно переводится на язык SQL. При переводе выражения на язык SQL нужно учесть, что во внутреннем подзапросе таблица A должна быть переименована, для того чтобы отличать ее от экземпляра этой же таблицы, используемой во внешнем запросе.

-------------------------------------------

Ну что тут скажешь ?
Блестяще !
21 янв 07, 04:04    [3671160]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
Мыш Летучий
Мне лично Каша нравится
потому что в ней не надо отделять серверное приложение от базы, а логику от данных,
во всяком случае мне так "удобнее".

С этого и надо было начинать. А мы , "реакционеры" бьёмся за отделение хранения данных от обработки и пользователского представления представления.
21 янв 07, 10:34    [3671248]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
2 V52: так и написано, DEVIDE?
21 янв 07, 10:36    [3671250]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
V52
Оператор деления

Реляционная алгебра: A(X,Y) DEVIDE BY B(Y)

Оператор SQL:

SELECT DISTINCT A.X
  FROM A
  WHERE NOT EXIST
    (SELECT *
        FROM B
        WHERE NOT EXIST
          (SELECT *
              FROM A A1
              WHERE
                  A1.X = A.X AND
                  A1.Y = B.Y));
Замечание. Оператор SQL, реализующий деление отношений трудно запомнить, поэтому дадим пример эквивалентного преобразования выражений, представляющих суть запроса.

Пусть отношение A содержит данные о поставках деталей, отношение B содержит список всех деталей, которые могут поставляться. Атрибут X является номером поставщика, атрибут Y является номером детали.

Разделить отношение A на отношение B означает в данном примере "отобрать номера поставщиков, которые поставляют все детали".

Ну что тут скажешь ?
Блестяще !

- Зина! Вы уже взрослая девушка, а тащите в рот всякую гадость. Вот заболит у вас живот - ни я, ни доктор Борменталь Вас лечить не будем.
21 янв 07, 11:21    [3671299]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
V52
Решил немного почитать теорию БД. По-моему это шедевр.
-------------------------------------------------------------------
-------------------------------------------

Ну что тут скажешь ?
Блестяще !

Вот так вот впервый раз в жизни почитал теорию и сразу во всем разобрался. О где Вы Дейты, Фагины, Мейры? Все ученые от ИТ все это время Вас ждали, чтобы Вы им все объяснили. Наконец то они дождались Ваших авторитетных комментариев. Может еще и премию Тьюринга за шедевриальный анализ теории дадут или на худой конец телевизор вручат.
Наверняка Вы Ваши тексты считаете покруче той теории. А если так то премия должна быть. За ту теорию то наверняка давали. Завидую - большие бабки срубите - на Каше за всю жизнь стока, наверное, не заработаишь.
21 янв 07, 12:27    [3671397]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Denis Popov
Member

Откуда: Санкт-Петербург
Сообщений: 7862
V52
Решил немного почитать теорию БД. По-моему это шедевр.
...
Разделить отношение A на отношение B означает в данном примере "отобрать номера поставщиков, которые поставляют все детали".
...
Ну что тут скажешь ?
Блестяще !

Странно, что вместо "NOT EXISTS" указан "NOT EXIST". Это пример где-то напечатан?
-- Список всех деталей.
create table B (
    y number(9)
  , constraint PK_N primary key(y)
);
-- Данные о поставках деталей.
create table A (
    x char(1)
  , y number(9)
  , constraint PK_A primary key (x, y)
  , constraint FK_A_B foreign key (y) references B(y)
);

-- Заполнение списка деталей.
insert into B (y) select rownum from dual connect by level < 10;

-- Заполнение данных о поставках деталей.
-- Постащик A поставляет все детали.
insert into A (x, y) select 'A', y from B;
-- Постащик B поставляет не все детали.
insert into A (x, y) select 'B', y from B where mod(y, 2) = 0;
-- Постащик C поставляет все детали.
insert into A (x, y) select 'C', y from B;
-- Постащик D поставляет не все детали. 
insert into A (x, y) select 'D', y from B where mod(y, 3) = 0;
commit;
Отобрать номера поставщиков, которые поставляют все детали.
SQL> select x
  2  from A
  3  having count(*) = (
  4    select count(*) from B
  5  )
  6  group by x;

X
-
A
C
21 янв 07, 15:36    [3671752]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Denis Popov
V52
Решил немного почитать теорию БД. По-моему это шедевр.
...
Разделить отношение A на отношение B означает в данном примере "отобрать номера поставщиков, которые поставляют все детали".
...
Ну что тут скажешь ?
Блестяще !

Странно, что вместо "NOT EXISTS" указан "NOT EXIST". Это пример где-то напечатан?

Да и DEVIDE вызывает сильные сомнения в адекватности источника...
21 янв 07, 16:51    [3671875]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 95 96 97 98 99 [100] 101 102 103 104 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить