Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ну я
Не поленился, проверил. Неверно.

Да, потому что Вам и сказали форменную чушь.
Такой запрос будет пол диапазона ключа блокировать что-ли
select count(*) from colorobj where color%2 = 0
А если условие хитрее? Несуществующие значения ключей не блокируюся, ибо слишком затратно. Единственное - на уровне изоляции serializable данный запрос заблокирует таблицу colorobj.
7 мар 06, 14:38    [2425846]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
Локшин Марк
А если условие хитрее? Несуществующие значения ключей не блокируюся, ибо слишком затратно. Единственное - на уровне изоляции serializable данный запрос заблокирует таблицу colorobj.

Вообще то select ничего не блокирует просто вы получите ответ по состоянию на начало запроса, т.е . все действия после игнорируются (oracle).
7 мар 06, 15:58    [2426253]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
мод
Вообще то select ничего не блокирует просто вы получите ответ по состоянию на начало запроса, т.е . все действия после игнорируются (oracle).

Ну так SergSuper у нас известно за MS SQL говорил (хотя не 2005), о чем и признался в следующем письме.
7 мар 06, 16:39    [2426470]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
victorat
Member

Откуда:
Сообщений: 2
Кто нить реально сравнивал скорость работы Каше с SQL запросами?
Мы вот сегодня поделали тестов... и увидели что Каше с агрегатами имеет большие проблемы производительности. На одном и том же сервере MSSQL дает выигрыш в несколько порядков.
7 мар 06, 19:29    [2426938]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
victorat
Member

Откуда:
Сообщений: 2
victorat
Кто нить реально сравнивал скорость работы Каше с SQL запросами?
Мы вот сегодня поделали тестов... и увидели что Каше с агрегатами имеет большие проблемы производительности. На одном и том же сервере MSSQL дает выигрыш в несколько порядков.


Добавлю что речь идет о запросах к одной-двум таблицам с количеством записей от 2 до 30 миллионов.
7 мар 06, 19:33    [2426948]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
SergSuper
c127
А после индексации, тоже без настроек, все по умолчанию, в секунду стало выполняться примерно 200 запросов по нахождению записи в таблице с 1млн. записей.

По-моему ошибка - 200 даже для такой железяки маловать.
Для сравнения попробовал у себя, только таблица полмилиона. За 5 сек выполнилось 100 000 запросов.
В любом случае время поиска 1 сек на в млн записей - неприемлемо много.


Нормально. 1 сек это без индекса. МССКЛ тоже пробегал такую таблицу примерно за секунду, по-моему эта скорость определяется в основном диском. Наверняка можно было ускорить, но мы ничего не настраивали, все по умолчанию. Плюс он вроде бы каждый раз компилировали запрос, не помню сейчас.

Локшин Марк

Да, потому что Вам и сказали форменную чушь.
Такой запрос будет пол диапазона ключа блокировать что-ли
select count(*) from colorobj where color%2 = 0
А если условие хитрее? Несуществующие значения ключей не блокируюся, ибо слишком затратно. Единственное - на уровне изоляции serializable данный запрос заблокирует таблицу colorobj.

Не чушь.
Sybase ASA, SELECT statements at isolation level 2:
At isolation level 2, Adaptive Server Anywhere modifies its procedures to ensure that your reads are repeatable. If your SELECT command returns values from every row in a table, then the database server acquires a read lock on each row of the table as it reads it. If, instead, your SELECT contains a WHERE clause, or another condition which restricts the rows to selected, then the database server instead reads each row, tests the values in the row against your criterion, and then acquires a read lock on the row if it meets your criterion.

SELECT statements at isolation level 3:
....
The number of anti-insert locks the server places can very greatly and depends upon your criteria and on the indexes available in the table.
....

На чтение блокируются строки, удовлетворяющие критерию (isolation level 2), на запись почти всегда блокируется вся таблица, согласен, но все-таки бывают исключения.


victorat
Кто нить реально сравнивал скорость работы Каше с SQL запросами?
Мы вот сегодня поделали тестов... и увидели что Каше с агрегатами имеет большие проблемы производительности. На одном и том же сервере MSSQL дает выигрыш в несколько порядков.

Вы на кеш проверяли на СКЛ запросах? Интересно как там с производительнорстью в М режиме, была обещана невероятная скорость.
8 мар 06, 00:00    [2427337]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Про отсталого чела "чала" понятно. Но моя-то в чем отсталость ? Я использую Oracle и Cache. Где отсталость ? Про плоские модели ничего вроде не говорил. Если не трудно, поясните что это за модели и как Вы их позиционируете ? Приведите пожалуйста, пример системы на MUMPS, использующей тока файлы, может будет понятнее о чем речь. Что в Oracle не РМД мне еще в институте объяснили. Если у Вас есть новые данные, так скажите, буду благодарен. Только без рекламы, пожалуйста. Про РМД, нашедшей применение на практике, смелое заявление. Уважаю.

Странные рассуждения о производительности, однако. Я реально вижу производительность реальных систем. Без приборов и тестов. Может народ не имеет представлений о реальной производительности ? Все системы на MUMPS, которые я видел или участвовал в разработке реально производительнее всех систем на Oracle и MSSQL, которые я видел или участвовал (только Oracle) в разработке. Ну может это все не правильные системы ? Поэтому и призываю высказаться тех, кто может реально что-то сравнивать, зная и то и другое.
А вот Fox я практически не знаю. Получается, что не по теме говорю. Может Fox, в отличие от Oracle, действительно круче MUMPS ? По слухам вроде бы не должно - вроде бы Fox примитивнее, чем Oracle. Или я заблуждаюсь ?
8 мар 06, 19:31    [2428291]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Мимо пробегал...
Guest
Действие третье (или четвертое?). Главный герой одел очередную маску, но умище то куда девать? Именно это его и выдает...

While Tom was eating his supper, and stealing sugar as opportunity offered, Aunt Polly asked him questions that were full of guile, and very deep-for she wanted to trap him into damaging revealments. Like many other simple-hearted souls, it was her pet vanity to believe she was endowed with a talent for dark and mysterious diplomacy, and she loved to contemplate her most transparent devices as marvels of low cunning.(Mark Twain. The Adventures of Tom Sawyer)
8 мар 06, 20:40    [2428357]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ораклоидальный мампсист

Я использую Oracle и Cache. Где отсталость ?

Например, в том что у Вас модели хухры-мухры. Вы не знаете, что Оракл РСУБД до сих пор. Это не отсталость?

ораклоидальный мампсист

Если не трудно, поясните что это за модели и как Вы их позиционируете ?

И в литературе и на этом форуме про МД слишком много было, чтобы начинать по новой. Так что их позиировать должны были и Вашем институте, где Вы учились, как фундамент БД.

ораклоидальный мампсист


Приведите пожалуйста, пример системы на MUMPS, использующей тока файлы, может будет понятнее о чем речь.

Вы сами сказали, что какую хошь модель на нем налабать просто. Но известно, что РМД не так просто налабать - в частности, и в МУМПС для работы с такими БД внедрение SQL поддерживается. Зачем, если там все так просто? Кроме того, МУМПС не СУБД. Значит сам он может поддерживать либо файловые системы, либо работать с СУБД, которые поддерживают таки серьезные МД.
Или на МУМПС и СУБД налабать просто? ЧАЛ такое пытался толкануть. Так что же Вы удивляетесь сходству с ЧАЛом?

ораклоидальный мампсист

Я реально вижу производительность реальных систем.

Где? На тестах TPC? Ну их там все могут видеть. Оракл там есть точно. Про Кэш не встречал. Или Вы свои системы как критерий Оракловой производительности толкаете? Так есть парни, которые работают на Ораклах и один у них быстрее другого.

ораклоидальный мампсист

Все системы на MUMPS, которые я видел или участвовал в разработке реально производительнее всех систем на Oracle и MSSQL, которые я видел или участвовал (только Oracle) в разработке.

А клиппер MUMPS обгоняет в ДОСе? Т.е. Вы думаете, что MUMPC делает лидеров TCP, но из скромности там не участвует? Или на нем нельзя делать ИС - он не СУБД? Или что с ним не так?

ораклоидальный мампсист

Ну может это все не правильные системы ?

Не то слово.

ораклоидальный мампсист

Может Fox, в отличие от Oracle, действительно круче MUMPS ?

До боли знакомый и затасканный ЧАЛом приемчик. Как бы между делом якобы установлено, что Оракл - одна из лидирующих СУБД не круче МУМПСа, и в этом даже сомневаться смешно, но может быть ФОКС круче? Тут можно еще посомневаться. О хде вы Гебельс с Мусолини? Вам такие тонкие приемы пропаганды не снились.
8 мар 06, 21:40    [2428423]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
зачем нам, Уважаемые коллеги,
ссориться ?

думаю у каждого из нас есть серьезные
выполненные проекты и не важно на чем они сделаны

с точки зрения разработки главное - хороший инструмент
понятно что и мы - мумпситы
и вы - эскуэльщики
работаем не на голом коде, а на хорошо пригнаной остнастке,
и давно уже не пишем стандартные вещи типа поисковиков
или генератора ввода вывода или отчетников - они есть у каждого
Ведем,так сказать, крупнопанельное строительство ударными темпами
(и только если очень надо - выкладываем некоторые детали из кирпича ).
Скорости вполне хватает и вам и нам и нашим клиентам
- стандартные блоки разогнаны по максимуму.
Нет проблем и с заказами.
Сделать мы с вами можем все что угодно и с SQL и без SQL.
Вопрос в коммерческой плоскости - что выгоднее использовать ?
Если я увижу коммерческую выгоду в применении SQL
- перейду на SQL сам и переведу свою фирму
Иначе в джунглях капитализма не выжить .
Только у нас в маленькой Латвии (население 2 миллиона)
50 (!) конкурирующих фирм делают то же что и мы -
производственно-бухгалтерские системы
(да еще "1c" адаптированая к Латвии - наш главный конкурент)

меня эта дискуссия убедила в силе реляционного подхода
Но и деревья хороши там где они к месту.
Видимо надо применять и то и это

предлагаю подвести черту в обсуждении и остаться добрыми
товарищами
9 мар 06, 09:55    [2429048]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
c127
Не чушь.
Sybase ASA, SELECT statements at isolation level 2:

Да, не знал про ASA такого. Но любой более-менее серьезный запрос там такую тучу блокировок понаставит, правда о чем они там честно и предупреждают :)
9 мар 06, 09:57    [2429061]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Локшин Марк
c127
Не чушь.
Sybase ASA, SELECT statements at isolation level 2:

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

У ASA всегда блокировки позаписные, с рождения (то есть с начала 90-ых годов). Есть еще табличкая блокировка, вызываемая явным оператором LOCK TABLE. Экскалации блокировок нет, однако как не странно, даже на большом кол-ве блокировок сервер не проседает, так как механизм блокировок существено отличается от блокировок ASE/MSSQL. Естественно самые сложный и критичный процесс блокировок идет на уровне serializable. Для этого в ASA есть специальные блокировки, которые ставятся не на записи, а на позиции сканирования в уникальных индексах, то есть получается позаписные блокировки дают уровень repeatable, а блокировки позиции сканирования на ветках индексов позволяют контролировать появление фантомов и гарантируют вместе с позаписными блокировками уровень serializable. Если интересно, как для сравнения с MSSQL в ASA работает механизм блокировок, здесь я выкладывал вторую часть статьи, посвященных транзакциям на сервере, где как раз подробно описывается весь механизм блокировок сервера.
9 мар 06, 10:05    [2429097]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
MX -- ALEX
меня эта дискуссия убедила в силе реляционного подхода
Но и деревья хороши там где они к месту.
Видимо надо применять и то и это

надо понимать что вы согласны что плоские структуры лучше реализуются на РБД а М имеет преимущества только на чистой иерархии ?
вот только применять и то и это в одной системе затруднительно, приходится выбирать в том и проблема. В большинстве случаев приходится жертвовать эффективностью иерархий ради общей эффективности - поэтому выбирают РБД.
9 мар 06, 10:29    [2429183]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
мод
MX -- ALEX
меня эта дискуссия убедила в силе реляционного подхода
Но и деревья хороши там где они к месту.
Видимо надо применять и то и это

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

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

лучше конечно если
увидел - пощупал - не понравилось - не бери.
9 мар 06, 10:59    [2429319]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
MX -- ALEX
меня эта дискуссия убедила в силе реляционного подхода
Но и деревья хороши там где они к месту.
Видимо надо применять и то и это

надо понимать что вы согласны что плоские структуры лучше реализуются на РБД а М имеет преимущества только на чистой иерархии ?
вот только применять и то и это в одной системе затруднительно, приходится выбирать в том и проблема. В большинстве случаев приходится жертвовать эффективностью иерархий ради общей эффективности - поэтому выбирают РБД.
А что такое плоские структуры и неплоские структуры?
9 мар 06, 12:01    [2429721]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
mir
А что такое плоские структуры и неплоские структуры?
Плоские, это двумерные структуры типа таблиц. Неплоские, это иерархические, например многоуровневые классы. Как выяснилось уровень класса, это таже таблица.

Вы действительно верите, что реляционная модель годится на все случаи жизни, а главное будет годится? В свое время в физике существовала только волновая теория света. Казалось она учитывает все. Со временем некоторые явления становилось объяснять все сложнее (давление света и тд). Появилась квантовая теория. Уверен, что подобие квантовой теории существовало, даже до волновой теории (теория атома). Новый импульс квантовой теории придали статистические методы и тд.

Реляционную модель вполне можно соотнести с волновой теорией и рассматривать всё через отношения (связи между частицами). Думаю, что появление объектных моделей не случайно. Медленно, но неизбежно они набирают силу. Фактически, объектная модель отражает многие идеи из квантовой теории (частицы связанные между собой). То, что нельзя или сложно представить в РМД, в ОМД представляется и реализуется. Мне лично было интересно послушать мнение сторонников Cache, Zigzag, db4o и прочего несовсем (или совсем не) реляционного.
9 мар 06, 12:48    [2430091]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
токарь

Реляционную модель вполне можно соотнести с волновой теорией и рассматривать всё через отношения (связи между частицами).

Здесь соотносили с мерсидевами - шо проще.

токарь

Фактически, объектная модель отражает многие идеи из квантовой теории (частицы связанные между собой).

Вы уверены что под воновой не имеют ввиду кванотовую, и противопоставляют карпускулярной под которой имеют в виду не кванотовую?
Видете что значит брать аналогию, котороая сама по себе не проста, так еще и непонятна обоснованность такой аналогии.

токарь

Думаю, что появление объектных моделей не случайно. Медленно, но неизбежно они набирают силу.

Вот это в применении БД не очевидно. Пик прошел лет 10 назад. С другой стороны РСУБД включают поддержку ОО. Т.е. объединяют кванотовое и не квантовое.

токарь

Мне лично было интересно послушать мнение сторонников Cache, Zigzag, db4o и прочего несовсем (или совсем не) реляционного.

Знание о факте их существания безусловно безусловно имеет значение для общей эрудиции.
9 мар 06, 14:54    [2430949]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
До тех пор пока у Вас РМД - это таблицы в которых лежат цифири (или буквы), то у Вас будут проблемы. ИМХО все наборот. Описание всех этих сложных струкутр можно и нужно рассматривать как определение отношений. Например я утверждаю, что
сейчас добиваю
Определение сложной ссылочной структуры, в которой корректно путевое выражение n1.*.nn.nm. *.nz (где ni – любые, не обязательные разные, имена, а знак * означает произвольную последовательность таких имен) можно рассматривать как определение переменной отношения с именем 'n1.*.nn' , в котором определен скалярный атрибут с именем 'nm.*.nz'.
Соотвестсвенно мы можем написать SELECT nm.*.nz FROM n1.*.nn и формально это выражение будет корректным с позиции РМД.
9 мар 06, 15:54    [2431318]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
токарь
Мне лично было интересно послушать мнение сторонников Cache, Zigzag, db4o и прочего несовсем (или совсем не) реляционного.

Не заменяя обсуждения, дополнительная информация:
Database Systems That Don't Fit Other Classifications
Нереляционный - этот термин относится не совсем к нетабличным СУБД. Если в СУБД нет встроенных средств организации именно таблиц, но их можно изобразить программно, то в этой СУБД можно (необязательно, но можно) реализовать реляции. Так же как на движке поверх dbf можно изобразить нетабличную СУБД. Неточные формулировки (реляционная, нереляционная) сами по себе порождают недопонимание. Терминологию для того и выдумали чтобы понимать друг друга. Надеюсь, что слова "можно" здесь никто не прочитает как "нужно" или тем более "я предлагаю".
9 мар 06, 16:05    [2431382]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
токарь
mir
А что такое плоские структуры и неплоские структуры?
Плоские, это двумерные структуры типа таблиц. Неплоские, это иерархические, например многоуровневые классы. Как выяснилось уровень класса, это таже таблица.
Так и знал. Одну странную фразу "плоские структуры" пытаются пояснить еще более странной "двумерные структуры". Да еще не просто "двумерные структуры", а "вроде таблиц". Учитывая, что термин "таблица" вообще не имеет определения (в отличие от отношения), это пояснение вообще ничего не поясняет. А вы уверены, что отношения РМД и таблицы -- это одно и то же? Я нет. А вы уверены, что они вообще "двумерные" (вариант, "плоские")? Я нет. Разговоры о "плоских" структурах" просто очень показательны. Это практически лакмусовая бумажка: понимает ли четко человек то, о чем говорит.
токарь
Вы действительно верите, что реляционная модель годится на все случаи жизни, а главное будет годится?
Нет. А что, кто-то говорил, что верит? Об этом вы вообще первый речь завели.
токарь
В свое время в физике существовала только волновая теория света. Казалось она учитывает все. Со временем некоторые явления становилось объяснять все сложнее (давление света и тд). Появилась квантовая теория. Уверен, что подобие квантовой теории существовало, даже до волновой теории (теория атома). Новый импульс квантовой теории придали статистические методы и тд.
Реляционную модель вполне можно соотнести с волновой теорией и рассматривать всё через отношения (связи между частицами). Думаю, что появление объектных моделей не случайно. Медленно, но неизбежно они набирают силу. Фактически, объектная модель отражает многие идеи из квантовой теории (частицы связанные между собой). То, что нельзя или сложно представить в РМД, в ОМД представляется и реализуется. Мне лично было интересно послушать мнение сторонников Cache, Zigzag, db4o и прочего несовсем (или совсем не) реляционного.
Это всё абстрактные рассусоливания. К делу отношения не имеют, а живо напоминают про "космические корабли, которые бороздят Большой театр".
9 мар 06, 16:36    [2431577]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
mir
А что такое плоские структуры и неплоские структуры?

В данном контексте это образное выражение.
Картотека - "плоская"
Цех-участок-рабочее место - "иерархия"
В М иерархия склеивается в один индекс, тем и достигается мах скорость.
При этом только один путь поиска быстрый, все остальное - full scan
9 мар 06, 16:48    [2431633]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ну я
[quot токарь]Нереляционный - этот термин относится не совсем к нетабличным СУБД. Если в СУБД нет встроенных средств организации именно таблиц, но их можно изобразить программно, то в этой СУБД можно (необязательно, но можно) реализовать реляции. Так же как на движке поверх dbf можно изобразить нетабличную СУБД. Неточные формулировки (реляционная, нереляционная) сами по себе порождают недопонимание. Терминологию для того и выдумали чтобы понимать друг друга.
Если вы сторонник четкой и общепризнанной терминологии (как и я), то к чему вы только что понаписали столько фантастических толкований известный терминов? И новый фантастических прибавили? Какие-то "нетабличные СУБД" (что бы это значило?)
Итак, для вас понятия "реляционная", "нереляционная" -- неточные, и вызывают недопонимание? Для современного IT-специалиста это звучит смехотворно. Такое утверждение может свидетельствовать о глубине именно ваших познаний, и не более того. Реляционная СУБД -- СУБД, реализующая реляционную модель данных (это для вас тоже нечеткое понятие?). Не реализует -- значит нереляционная. Точка. Абсолютно ничего неточного. Если мало, есть, к слову, еще и общеизвестные 12 правил Кодда, определяющих, какая СУБД является реляционной. Не надо фантазий на эту тему, пожалуйста.
9 мар 06, 16:50    [2431639]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
А что такое плоские структуры и неплоские структуры?
В данном контексте это образное выражение.
Картотека - "плоская"
Цех-участок-рабочее место - "иерархия"
В М иерархия склеивается в один индекс, тем и достигается мах скорость.
При этом только один путь поиска быстрый, все остальное - full scan
Я не понимаю, что значит "в данном контексте" в техническом разговоре о структурах данных. При чем здесь контекст? Я понимаю, что значит "образное выражение" в поэзии, но не понимаю, при чем здесь разговор специалистов (хотелось бы верить) на техническом языке. Я не понимаю, почему для вас картотека - "плоская". Вы видели картотеку вживую? У нее есть высота, ширина и длина. Образнее некуда. Может, хватит образности? Хотелось бы строгости и точности.
9 мар 06, 16:57    [2431683]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
vadiminfo
токарь

Думаю, что появление объектных моделей не случайно. Медленно, но неизбежно они набирают силу.

Вот это в применении БД не очевидно. Пик прошел лет 10 назад. С другой стороны РСУБД включают поддержку ОО...
Вы ошибаетесь. Конечно пик полного противопоставления ОМД к РМД прошел. Кажется это было лет 18 назад. Прошли еще две волны подтверждающие только, что идет процесс интеграции двух подходов. Попытки включить ОО-поддержку в РМД продолжаются, но успешно ли? Вопрос что на основе чего будет базироваться остается открытым. Весьма вероятно, что сторонникам ОМД будет проще реализовать реляционный (табличный) подход.
9 мар 06, 16:59    [2431699]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
mir
токарь
mir
А что такое плоские структуры и неплоские структуры?
Плоские, это двумерные структуры типа таблиц. Неплоские, это иерархические, например многоуровневые классы. Как выяснилось уровень класса, это таже таблица.
Так и знал. Одну странную фразу "плоские структуры" пытаются пояснить еще более странной "двумерные структуры". Да еще не просто "двумерные структуры", а "вроде таблиц". Учитывая, что термин "таблица" вообще не имеет определения (в отличие от отношения), это пояснение вообще ничего не поясняет. А вы уверены, что отношения РМД и таблицы -- это одно и то же? Я нет. А вы уверены, что они вообще "двумерные" (вариант, "плоские")? Я нет.
Теория только направляет. Диктует реализация. Вы можете говорить сколько угодно об отношениях. Важно, что все их реализации имеющие пока успех базируются на таблицах. Соответственно для них (Oracle, SQL Server и тд) и их поклонников, отношения это таблицы. Другое дело, как эффективно будут реализованы отношения в О(Р)СУБД?
9 мар 06, 17:17    [2431816]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить