Опять... (Обреченно так..) S>1.При работе с MS SQL у разработчика много головной боли с блокировками.
Отчасти это верно, но ты не предсатвляешь какой головной болью может обернуться версионность, если в нее встрять ненароком. Вообще Оракловский механизм concurrency далек от идеала, и хотя является одним из лучших в индустрии, MSSQL'ный ничем ему не уступает...
Впрочем этот вопрос поистине религиозный и заслуживает отдельного обсуждения.
S>2.Отсутствие в MS SQL : S> а.древовидные запросы
Это так называемый syntactic shugar — таже самая функциональность делается руками причем заметно эффективнее.
S> б.поддержка запросов типа select * from(<любой select>),
В ANSI SQL это называется derived table, в MSSQL есть чуть-ли не с самого начала — замечательным образом работает.
S>3.В Oracle 9.2 введен новый тип данных XMLType, очень удобная работа с XML(описывать долго).
А к RDBMS это каким боком? Впрочем поддержка xml — это опять-таки отдельная история.
S>4. У Oracle два типа триггеров(на запрос и на строку..у MS SQL только на запрос)
Нет, это не так. Просто триггеры в MSSQL, так же как и сам SQL предназначены для работы с множествами, что вообщем идеологически правильнее, логичнее, функиональнее и в конечном итоге эффективнее.
S>5. У Oracle есть поддержка безопасности на уровне строк(может и MS SQL тоже есть, но пока не видел)
Этого нет, то так же при желании элементарно делается руками, то есть данная функциональность опять-таки является syntactic shugar.
S>Это, пожалуй, самые весомые аргументы в пользу Oracle.Есть много более "мелких".
Нет, весомые аргументы в пользу Оракл пожалуй немного другие, а это все мелочи, тем более, что не все из них вообще в пользу Оракл.
Вообще складывается такое впечатление, что люди пытающиеся сравнивать различные СУБД толком не работали ни с одной из них, и то обсуждение на SQL.RU, на которое тут давали ссылку, — яркий тому пример. Все претензии относятся к разряду анекдотов про "Як москали наше пыво называют".
Опять-таки хочу напомнить, что не имеет смысла сравнивать СУБД в целом, оставим это маркетологам у них это заметно лучше получается — их этому учат в конце-концов. У нас же здесь, смею надеяться, техническая конференция, поэтому имеет смысл разбирать отдельные технические решения, и оценивать их эффективность в применении к реальным задачам, а не обобщать, сравнивая теплое с мягким.
Здравствуйте, Аноним, Вы писали:
А>Сравнивать Oracle и MSSQL — это то же, что сравнивать Мерседес и Жигули. Оба в принципе могут ездить, только на Мерсе удобнее и быстрее.
Если уж проводить подобную анологию, тогда это сравнение между Land Cruiser (Oracle) и 325 бэхой... полноприводной (MSSQL).
И там и там можно ездить с комфортом, по бездорожью на ждипе сподручнее, но ездть почему-то больше приходится по трассе.
А>Возможности и скорость в Oracle гораздо больше.
Пффф... [-]
По возможностям именно RDBMS они абсолютно одинаковы.
В скорости, для очень широкого класса задачь MSSQL банально быстрее, так что вот так вот откровенно уж не правду говорить не надо.
А>Кроме того Oracle — кросплатформенный.
Ну вот это да, это есть.
А>Всех плюсов не перечтешь, пока не поработаешь сам с Ораклом лет несколько.
И столько же глюков, недоработок и косяков соберешь.
А>Но будем откровенны — в MS SQL есть один плюс — он дешевле Оракла, по-моему, раза в два.
И этот плюс далеко не единственный. MSSQL продуманнее, лаконичнее и проще, как следствее более предсказуемый и надежный.
Вообще сравнивать DB в отрыве от задачи — мягко говоря не корректно, можно наплести все что угодно, и попробуй докажи, что я не прав.
О каком-либо тотальном превосходстве какой-нибудь СУБД из тройки лидеров, для более менее широкого класса задач, на данный момент говорить не приходится, по возможностям и производительности они примерно одинаковы, дальше все зависит от специфики и радиуса кривизны рук разработчика.
Если стоит проблема выбора, то тадо брать ту СУБД, которую лучше знают те, кому придется с ней работать, все остальное — разговоры в пользу бедных.
Сравнивать Oracle и MSSQL — это то же, что сравнивать Мерседес и Жигули. Оба в принципе могут ездить, только на Мерсе удобнее и быстрее.
Возможности и скорость в Oracle гораздо больше. Кроме того Oracle — кросплатформенный. Всех плюсов не перечтешь, пока не поработаешь сам с Ораклом лет несколько.
Но будем откровенны — в MS SQL есть один плюс — он дешевле Оракла, по-моему, раза в два.
ЧТо касается средств разработки — это никак не связано с БД. Это дело вкуса
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>открою страшную тайну .. ява (java) используется как язык сторед процедур, и не поверишь ... тригеров СУБД M>Внимание вопрос знатокам. Для чего он там используется?
M>Чтобы было проще, и более предметно. M>Набросайте мне, если не сложно, небольшую процедуру на яве, которая делает джойн двух абстрактных табличек, желательно с использованием какой-нибудь подсказки оптимизатору, например, чтобы он использовал определенный индекс.
Да ну его спорить с ним, Иван. Ни к чему конструктивному это не приведет. Ну не знает человек, какие роли играют апп-сервер и дата-сервер в теоретической модели многоуровневых приложений. И боюсь, переубедить его мы не сможем. Ничего, выйдет юкон — проще будет. Хотя тогда скорее всего начнется бой насмерть — апологеты МССКЛ начнут кричать ура, а апологеты оракл — "у нас это еще когда было!". Но по крайней мере можно будет сравнивать две более-менее эквивалентых системы. А то получается мы сравниваем катер с пароходом, причем ты просишь ограничиться сравнением шлюпки от парохода с катером, а тебе отвечают "нифига, пароход — тоже плавсредство"
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
O>Специально написанные продукты разработки для Oracle, очень просты и удобны для написания действительно больших приложений, я имею в виду Oracle Developer Studio, одни из наиболее часто используемых это Oracle Forms, Reports, JDeveloper, Designer (ERP-диаграммы, бизнесс потоки и т.д.) и т.п.
А вот этого не надо. Все, что пишет сам Oracle и при этом ЭТО имеет какой-то GUI — полное убожество . Начиная с SQL+ (даже стрелки не работают). Ну, а Developer Suite — это вообще атас.
Forms — изделия из под него выглядят уроженцами эры доисторического материализма.
Reports — даже делфишный QuickReport лучше.
JDeveloper — просто средненькая Java IDE.
Designer — при живых ERWin и особенно Sybase PowerDesigner — отстой.
При этом весь этот бред занимает 1 Гб и ужасно тормозит (по крайней мере, под виндами).
Здравствуйте, aston, Вы писали:
B>>Скажи мне альтернативу формсам?-) A>Delphi, VFP, PowerBuilder. Тот же .NET
VFP и PB не видел, но Дельфи и .NET ты скорее зря привел в качестве примера.
Формсы рулят по скорости создания надежно работающих приложений.
А на дельфи и .NET столько всего придется делать, чтобы оно хоть как-то зажило.
A>Ну это да, есть такое. Но, IMHO, писать одно и то же приложение как под Win, так и под Web — это сознательно ограничивать себя убогими средствами Web. Все таки в системе должен быть презентативный слой — один — с качественным ГУИ — для Win. Другой — с убогим — для Web.
Это сразу и было понятно, что ты не в курсе возможностей формсов.
Здесь речь шла о том, что вот есть у меня разработанные 10 лет назад FMX.
Клиент-сервер и все такое. А заказчик вдруг говорит — хотим тонкого клиента.
А я ему в ответ — завтра. И завтра у меня вся система на тонком клиенте. Вся.
Все формы и все отчеты вне зависимости от их количества.
Кто так может?-))
Павел
p.s если понимать цели, задачи и возможности, то даже формсы рулят. А у MS для MSSQL такого нет.
У них даже репортера своего нет, о чем тут можно разговаривать и что тут можно сравнивать вообще?-)
Здравствуйте, Аноним, Вы писали:
А>может кто все же догадается посмотреть на промышленые реализации ?
Дык, где они?
А>1. на как и чем крутится Lotus Notes — это не RDBMS, но есть вариант что под низом у нее все таки DB2.
Ну ты посоветовал...
Во первых на это чудо лучше вообще не смотреть.
А во вторых у Лотуса там в нутрях не DB2. Я тебе больше скажу, ИБМ-цам занадоело смотреть куда лотус катится и они это дело как раз под ДБ2 переписывать собираются, чтобы к этим вечным тормозам нормальный тепловоз приделать.
А>2. как и где работает промышленая ООСУБД Cashe
Ага ОО.. Где там эти две буквы? Даже сами хлопцы из интерсустемса аккуратненько называют ее "постреляционная", так как не смотря на все потуги она ни какая не объектная, а очень хорошо написанная иерархическая БД. Ну максимум сетевая.
А>п1 ответит на 2/3 вопросов ...
Как много нам открытий чудных...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>открою страшную тайну .. ява (java) используется как язык сторед процедур, и не поверишь ... тригеров СУБД M>Внимание вопрос знатокам. Для чего он там используется?
M>Чтобы было проще, и более предметно. M>Набросайте мне, если не сложно, небольшую процедуру на яве,
Это задача не для Java, конечно, здесь один SQL.
Тем не менее задач которые решает Java в хранимых процедурах и тригерах не так уж мало. Например в тригере может понадобится
-зашифровать или проанализировать данные ипользуюя какую-либо существующую библиотеку
-открыть сетевое соединение (хоть сокеты, хоть веб-сервисы) и сообщить куда следует
-соконнектиться и что-то сделать в другой базе (например из Oracle в Interbase)
Здравствуйте, skyline, Вы писали:
S>Мне, например, очень нравится такое преемущество Oracle, как select for update.
Это не преимущество — это заплатка..
В некоторых случаях, когда необходимо, чтобы читающие запросы все-таки блокировали пишущие, и применяется for update.
S>И, по моему, в SQL сервере такого нет.
Есть...
with (holdlock), with (updlock) или with(xlock) в зависимости от необходимой строгости блокировки и уровня изоляции.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Smileman, Вы писали:
Попробую проанализировать Ваш ответ Merle: S>>1.При работе с MS SQL у разработчика много головной боли с блокировками. M>Отчасти это верно, но ты не предсатвляешь какой головной болью может обернуться версионность, если в нее встрять ненароком.
Что значит "встрять ненароком" ? Прошу конкретный пример. M>Вообще Оракловский механизм concurrency далек от идеала
опять же не вижу примера..одна пустая фраза M>, и хотя является одним из лучших в индустрии, MSSQL'ный ничем ему не уступает...
опять же похвалить оракл и не забыть MS SQL M>Впрочем этот вопрос поистине религиозный и заслуживает отдельного обсуждения.
с этого и надо было начинать
Т.е очевидно, что в предыдущем абзаце ничего конкретного сказано не было..все пустые фразы "ненароком, далек от идеала,ничем не уступает, ты не представляешь".
S>>2.Отсутствие в MS SQL : S>> а.древовидные запросы M>Это так называемый syntactic shugar — таже самая функциональность делается руками причем заметно эффективнее.
Это вероятнее всего было прочитано в статье от Микрософта из серии...то чего у нас пока нету можно сделать руками и даже лучше...сомневаюсь, что можно это сделать быстрее
S>> б.поддержка запросов типа select * from(<любой select>), M>В ANSI SQL это называется derived table, в MSSQL есть чуть-ли не с самого начала — замечательным образом работает.
У меня на MS SQL 2000 не работает..это факт..много раз проверял..может, в синтаксисе ошибся...
но запрос select count(*) from(select * from <имя_таблицы>) не работает S>>3.В Oracle 9.2 введен новый тип данных XMLType, очень удобная работа с XML(описывать долго). M>А к RDBMS это каким боком? Впрочем поддержка xml — это опять-таки отдельная история.
Хоть что-то но ответить надо... S>>4. У Oracle два типа триггеров(на запрос и на строку..у MS SQL только на запрос) M>Нет, это не так. Просто триггеры в MSSQL, так же как и сам SQL предназначены для работы с множествами, что вообщем идеологически правильнее, логичнее, функиональнее и в конечном итоге эффективнее.
Опять не ясно. И опять одни лишь слова "идеологически правильнее, логичнее, функиональнее и в конечном итоге эффективнее".Триггеры прежде всего направлены для реагирования на события..связь триггером и множеств как-то не очень ясна.
S>>5. У Oracle есть поддержка безопасности на уровне строк(может и MS SQL тоже есть, но пока не видел) M>Этого нет, то так же при желании элементарно делается руками, то есть данная функциональность опять-таки является syntactic shugar.
Опять же ничего не сказано конкретного...фразы "элементарно..при желании" уже обязательны. S>>Это, пожалуй, самые весомые аргументы в пользу Oracle.Есть много более "мелких". M>Нет, весомые аргументы в пользу Оракл пожалуй немного другие, а это все мелочи, тем более, что не все из них вообще в пользу Оракл.
Опять одни лишь слова..
В общем, уважаемый Merle, Вы демагог. Прочем, неплохо умеющий подбирать слова и строить фразы.
M>{ SELECT office_addr INTO :addr FROM employees
M> WHERE empnumber = :empno }
M>Вот это тоже Ява? Так что не зря..
Смотрим начальный пост:
_Gt>открою страшную тайну .. ява (java) используется как язык сторед процедур, и не поверишь ... тригеров СУБД
Ключевая фраза — "используется как язык сторед процедур". Причем сам SQL встроен в язык. Переключение между контекстами происходит автоматически. Так что можно Java использовать вместо PL/SQL и заменить PL/SQL-ный код:
CRETATE OR REPLACE FUNCTION getEmployeeAddress(empno IN INTEGER) RETURN VARCHAR2 // line 10
DECLARE
Result VARCHAR2(255);
BEGIN
SELECT office_addr
INTO Result
FROM
employees
WHERE
empnumber = empno
RETURN (Result);
END;
на явовский, приведенный выше.
Полезно, когда возможностей процедурного языка PL/SQL не хватает и надо использовать объектную модель с наследованием и прочей чухней. А Oracle взял и интегрировал Java так, что пишешь на ней, как на PL/SQL, без всяких коннекшенов, рекордсетов, коммандов и прочей лабуды. Так что Java является полноценным участником БД и рассматривать ее как какую-то примочку, не относящуюся к БД — не нужно. Причем этот Java'вский код хранится в самой БД, а не где-то в файлах, как в IB-UDF. Следовательно, смена платформы происходит безболезненно без всяких перекомпиляций.
Интересно, как в Yukon будут писаться SP на шарпе. Надеюсь, так:
public System.Data.SqlTypes.SqlString getEmpAddress(System.Data.SqlTypes.SqlInt32 empno)
{
System.Data.SqlTypes.SqlString empAddress;
EXEC SQL{
SELECT office_addr
INTO
@empAddress
FROM
employees
WHERE
empnumber = @empno
}
return empAddress;
}
Здравствуйте, <Аноним>, Вы писали: А>ерунда все это конечно весомый оргумет, но хотелось бы деталей ... например для реализации оракла. т.е. при каких условиях, какой выйгрышь и т.п. А>от Мерле кроме авторитетного заявления "Особенно учитывая каким образом Оракл мудрит с RW транзакциями при RC, а при snapshot'е все еще грустнее — там версионник сливает по определению." выудить ничего не удалось А>мой аргумент см чуть выше.
Просто Merle прямо в этом форуме уже дважды читал курсы лекций по особенностям поведения Oracle при выполнении RW транзакций. Вряд ли ему захочется делать это же в третий раз. По крайней мере до выхода нового оракла. А Андрей совершенно прав. Люители длинных RW транзакций положат как версионник, так и блокировочник. Если интересно почему — рекомендую все-таки пойти в книжный магазин. Трудно в форуме изложить 200 страниц теории. Вкратце и так все очевидно — deadlock это deadlock, независимо от стратегии изоляции. Поддержка изоляции съедает ресурсы, и чем длиннее транзакция, тем больше этих ресурсов. По поводу OLTP — версионники сливают. До выхода 10g говорить о выступлениях Oracle в OLTP было вообще смешно. Сейчас на tpc запощены результаты, которые позволяют Oracle надеяться на лучшее. Тем не менее, статус их до сих пор in review, а сопоставимая с МССКЛ цена транзакции в минуту достигается только в одном из варинатов. Я плохо знаю Оракл, поэтому не в курсе, какие такие изменения по сравнению с 9кой позволили им так вырваться вперед. Есть у меня подозрение, что они таки сделали блокировки со всеми теми эскалациями, которыми пугают юных оракл-девелоперов .
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Vasiliy_Krasnokutsky, Вы писали:
V_K>Добрый день, V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql. V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных. V_K>Желательно бы ссылки на статьи или книги.
V_K>Заранее благодарен, Краснокутский Василий
Лично мне больше нравится Оракл.
1.При работе с MS SQL у разработчика много головной боли с блокировками.
2.Отсутствие в MS SQL :
а.древовидные запросы
б.поддержка запросов типа select * from(<любой select>), т.е. во фразе from можно в скобках писать другой select(я пробовал на MS SQL, не получилось..может как-то и можно)
3.В Oracle 9.2 введен новый тип данных XMLType, очень удобная работа с XML(описывать долго).
4. У Oracle два типа триггеров(на запрос и на строку..у MS SQL только на запрос)
5. У Oracle есть поддержка безопасности на уровне строк(может и MS SQL тоже есть, но пока не видел)
Это, пожалуй, самые весомые аргументы в пользу Oracle.Есть много более "мелких".
Здравствуйте, Vasiliy_Krasnokutsky, Вы писали: V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql. V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных.
IMHO.
Сравнение этих двух БД бесполезно, так как это обсуждение может затянуться на очень большое время, и все равно ни чего, кроме оскорблений и ругательств не даст.
Все останутся при своем мнении.
По моему скромному мнению, из этих двух БД, Вам, надо выбирать ту, с которой именно Вам будет проще разобраться, т.е. по какой БД у Вас больше информации, больше книжек, больше знакомых, знающих эту БД и могущих быстро помочь в случае какого-нибудь небольшого затруднения.
Сравнение производительности работы Oracle и MS SQL Server, для Вас вообще не должно играть ни какой роли. Разницу в производительности в своих приложениях, я уверен, Вы не заметите.
Да здравствует MySQL — самый продуманный, лаконичный, простой и, как следствие, более предсказуемый и надежный сервер баз данных. Притом в скорости он для очень широкого класса задач (известных узкому кругу лиц) банально быстрее (теоретически).
B>Скажи мне альтернативу формсам?-)
Delphi, VFP, PowerBuilder. Тот же .NET
B>Я хочу быстро и качественно делать БД-приложения, причем, если мне надо будет B>переносить его под веб, то чтобы я ничего не делал вообще, а оно само )
Ну это да, есть такое. Но, IMHO, писать одно и то же приложение как под Win, так и под Web — это сознательно ограничивать себя убогими средствами Web. Все таки в системе должен быть презентативный слой — один — с качественным ГУИ — для Win. Другой — с убогим — для Web.
Здравствуйте, <Аноним>, Вы писали:
А>создается 2 курсора, в цикле оба фетчатся в массивы джавы. далее происходит "джоин" массивов и возвращается 3й массив ... движек SQL используется только для создания курсора, т.к. поросто нет другой конструкции создания курсора. т.е. всю обработку данных (не просто бизнес логику) можно выполнить джавой. вопрос на сколько это эфективно для данной задачи мне не важно.
Используя подобную логику я могу утверждать, что в MSSQL'е работа через DMO — это аналог Оракловской Явы и даже круче, там вообще ни одной SQL команды не встречается.
Ява — это инструмент работы с бизнес логикой, а SQL с логикой хранения. И Бизнес логика в задачи БД не входит.
А>фокспро/клипер имел только (!) процедурный язык для обработки данных, SQL это все-го лишь один из 3х (+ pl/sql, java) движков в оракле, который ими во всю используется, для решения многих задач.
И в итоге любое, более менее сложное приложение превращается в дикую смесь из этих трех языков, в которой без поллитры не разгребешся. Потому как достать данные по человечески можно только через SQL, чем движек БД и занимается и на этом БД заканчивается. А дальше начинается шаманство с PL/SQL'ем и Явой — зато все на сервере.
А>у меня встречная просба — выдайте мне ANSI SQL92 — для обстрактной таблички работников и зарплаты, нужно получить колонки со средней зарплатой, и сумой, вышестоящих, типа: А>1. Иванов 100 100 100 А>2. Петров 70 85 170 А>3. Сидоров 60 76 230
А каким образом организованы эти абстрактные таблички работников и зарплаты?
В любом случае операторов SUM, AVG и GROUP BY никто не отменял.
А>p.s. для тех кто непонял — встречаются задачи обработки данных которые решить SQL или невозможно или сложно.
Для тех кто не понял — обработка — это бизнес логика, а SQL и БД — это хранение.
Здравствуйте, Merle, Вы писали:
M>Таким образом Ява — это язык описания бизнес логики, а не логики хранения реляционных данных, и непосредственно к БД имеет мало отношения.
Итого Вы утверждаете
1. На Java лучше реляционные операции не делать, делать их на SQL или PL/SQL.
2. На SQL или PL/SQL бизнес логику делать нельзя лучше на Java.
3. В хранимых процедурах и тригерах бизнес-логику делать нельзя.
Отсюда логичный вывод что в хранимых процедурах и тригерах Jav-е не место.
С 1. согласен, за исключением _очень_ редких случаев если не голого SQL то PL/SQL для реляционных задач хватает с головой, они (языки) собственно десятилетиями для этого и разрабатывались. Про исключения хорошо пишет, например, Дейт.
По 2-3. это мнение популярное и распростаненное но не единственное. Например, дока к 7 Ораклу утверждает что серверная бизнес логика обязана быть в хранимых PL/SQL процедурах (а Oracle — это не просто db-сервер, а db-app сервер). Нужна ли полноценная 3-х уровневая архитектура зависит от задачи. Для широкого куруга бизнес приложений — да, но ими жизнь не ограничивается. Нельзя всех стричь под одну гребенку, это такая же крайность как и везде игнорировать mainstream-методы проектировния. Кроме вопросов проектирования не нужно забывать о производительности. Например, недвно сталкивался с задачей вставики сущности в сложную базу (~50 таблиц), куча логики и проверок не выражаемых ограничениями целостности, много ветвлений, алгоритм на PL/SQL занял 4 страницы, если это же все делалось бы на EJB (или COM/MTS), то за один раз бы создавалось пара сотен объектов. Задача была критична по времени выполнения, поэтому PL/SQL — единственное решение. То же и по Java, я приводил примеры где она может понадбится. Пропорции использования определяются опять же задачей.
Ситуация похожа, например, на то что в Java или .NET оставляют возможность вызова native-кода.
Здравствуйте, Victor Repetsky, Вы писали:
VR>Итого Вы утверждаете VR>1. На Java лучше реляционные операции не делать, делать их на SQL или PL/SQL.
Угу.
VR>2. На SQL или PL/SQL бизнес логику делать нельзя лучше на Java.
Вообщем да. Или любом другом языке нарошно для этого придуманом. На самом деле в дурацком =) английском языке есть два понятия layer и teir. Одно из них служит для описания логического слоя приложения, а другое — физического. Понятно, что идеала не существует и часть логического business layer'а как правило реализуется на SQL'е, но основная логика все равно ложится на код написанный на "более другом языке".
VR>3. В хранимых процедурах и тригерах бизнес-логику делать нельзя. VR>Отсюда логичный вывод что в хранимых процедурах и тригерах Jav-е не место.
Ну, пожалуй не так категорично, это уже больше вопрос проектирования и конкретной задачи.
Предыстория спора такова: мой оппонент утверждает что:
1. на T-SQL нельзя нормально работать, нельзя описать на нем бизнес-логику -> 2. Это есть недостаток MSSQL -> 3. У Оракла преимущество ввиду наличия Java.
А собственно мой поинт заключается в:
1. на T-SQL нельзя делать то, для чего он не предназначен, для операций же с реляционными данными он подходит очень и очень хорошо, а все остальное на нем делать просто не надо. Этот язык попросту не предназначен для описания БЛ.
2. Это не есть недостаток. Это просто другая концепция. Оракл предоставляет возможность описания БЛ в рамках сервера БД, MS(в текущей версии) предполагает, что лучше описывать БЛ в другом месте. Благо возможностей по написанию среднего слоя и клиентов MS предоставляет больше всех в индустрии, поэтому они не посчитали неободимым встраивать это в сервер.
3. С точки зрения СУБД ("чистой" СУБД, без app-заморочек), наличие Явы не есть преимущество, так как непосредственно задачами БД Ява не занимается и никаких плюсов не дает.
Если же рассматривать только Оракл, я еще раз повторюсь, то это безусловно вопрос архитектуры конкретного приложения.
VR>(а Oracle — это не просто db-сервер, а db-app сервер).
[+]
Именно это я и утверждал. Собственно это еще одна причина спора.
VR> Нужна ли полноценная 3-х уровневая архитектура зависит от задачи. Для широкого куруга бизнес приложений — да, но ими жизнь не ограничивается. Нельзя всех стричь под одну гребенку, это такая же крайность как и везде игнорировать mainstream-методы проектировния.
[+]
Здравствуйте, theOne, Вы писали:
O>Здравствуйте, Merle, Вы писали:
M>>Я все еще жду определения RDBMS.
O>Кстати, это еще в будущем, о чем я сейчас собираюсь сказать, для нас разработчиков. Но у нас будет неплохой шанс очень приятно и свободно использовать Оракл как Объектную БД. На сегодняшний день уже восьмерка стала Объектно-Реляционной БД. И появление Java далеко не случайность. Уже есть смысл спрашивать определение ORDBMS.
Ребята, возможность объявить статический метод класса хранимой процедурой не делает из RDBMS ODBMS. Вот когда будет работать что-то типа
Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
можно будет вернуться к этому разговору.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Вот когда будет работать что-то типа S>Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager) S>можно будет вернуться к этому разговору.
Для Оракл:
CREATE TYPE address AS OBJECT
( hno NUMBER,
street VARCHAR2(40),
city VARCHAR2(20),
zip VARCHAR2(5),
phone VARCHAR2(10) );
CREATE TYPE person AS OBJECT
( name VARCHAR2(40),
dateofbirth DATE,
homeaddress address,
manager REF person );
CREATE TABLE persons OF person
( homeaddress NOT NULL,
UNIQUE (homeaddress.phone),
CHECK (homeaddress.zip IS NOT NULL),
CHECK (homeaddress.city <> 'San Francisco') );
--Создаем объектный тип и объектную таблицу OID (не ROWID!!!!) primary keyCREATE TYPE employees_typ AS OBJECT
(e_no NUMBER, e_address CHAR(30));
CREATE TABLE employees_obj_t OF employees_typ (e_no PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY;
-- Затем можно ссылаться на этот объект двумя способами:CREATE TABLE departments_t
(d_no NUMBER,
mgr_ref REF employees_typ SCOPE IS employees_obj_t);
CREATE TABLE departments_t (
d_no NUMBER,
mgr_ref REF employees_typ
CONSTRAINT mgr_in_emp REFERENCES employees_obj_t);
Не вижу какая трудность по сохранению объектов и извлечению таковых? Такое ощущение, что вы ответы на ходу иногда пытаетесь придумать. Хотя как говорят: "Не уверен — не обгоняй!".
По-моему разговор съезжает с темы. Давай вернемся немного назад. Вот сюда:
Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
Это гипотетический язык. Семантика ясна? На всякий случай я поясню: мы хотим найти множество всех объектов, которые реализуют интерфейсы IAmountable и ISecuredObject. При этом значение, возвращаемое методом IAmountable.Amount() должно превышать 100, а метод ISecuredObject.AllowsAccess() должен возвращать "истина" при передаче ему в качестве параметра менеджера текущего пользователя.
В базе живет, скажем, N ~ 1e7 объектов. Интерфейс ISecuredObject реализован примерно в 300 из 1000 зарегистрированных классов; интерфейс IAmountable — в 20. Одновременно с системой работают на R/W 50 пользователей, на R 500.
Ты не мог бы ответить на несколько простых вопросов (не вдаваясь в технические детали):
1. Каким образом будет выглядеть план этого запроса?
2. Какова ожидаемая зависимость быстродействия этого запроса от N?
3. Каким образом можно построить этот план, имея на входе декларативное описание запроса, вроде вышеописанного? Учитывая то, что вообще говоря есть инкапсуляция, т.е. все состояние объекта помечено как private.
Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым.
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А>>1. на как и чем крутится Lotus Notes — это не RDBMS, но есть вариант что под низом у нее все таки DB2. А>Ну ты посоветовал... А>Во первых на это чудо лучше вообще не смотреть. А>А во вторых у Лотуса там в нутрях не DB2. Я тебе больше скажу, ИБМ-цам занадоело смотреть куда лотус катится и они это дело как раз под ДБ2 переписывать собираются, чтобы к этим вечным тормозам нормальный тепловоз приделать.
не видели рекламу когда не нужно больше говорить ?
Relational database management system
The remainder of the data used by the LMS is stored in a third-party relational database management system (RDBMS). Although the RDBMS is a third-party product, it is a fundamental component of the Lotus Learning Management System. Data regarding user privileges, courses, and resources is stored in the database management system and accessed as needed.
как я и предполагал под низом одна из 3х бд db2, oracle или mssql
Здравствуйте, Sinclair, Вы писали:
S>Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета.
Вот к примеру кондитерская фабрика. В среднем ок. 100 позиций в накладной, ок. 200 накладных в сутки (оптовые продажи). При минимальной 3-хскладовой системе имеем 5 накладных (прих., расх., 2 перемещения). Итого 100 тыс. записей в сутки. Хранить в оперативной БД нужно данные минимум за пару лет.
100тыс. * 365 * 2 это почти 1е8. И это довольно скромная оценка. Предлагаю взять 1е9 записей как верхнюю оценку.
Здравствуйте, Аноним, Вы писали:
А>не видели рекламу когда не нужно больше говорить ?
Категоричность Ваших суждений, милейший, соперничает только с поверхностностью Ваших же взглдов...
А>Relational database management system А>The remainder of the data used by the LMS is stored in a third-party relational database management system (RDBMS). Although the RDBMS is a third-party product, it is a fundamental component of the Lotus Learning Management System.
Слово Learning в названии не смущает? Это компонент для обучения.
Когда говорят Lotus, то обычно подразумевают систему документооборота Notes/Domino. Так вот там, "под низом" никакой реляционностью и не пахнет, я вас умоляю...
А> Data regarding user privileges, courses, and resources is stored in the database management system and accessed as needed. А>как я и предполагал под низом одна из 3х бд db2, oracle или mssql
Е))))))))))))))))
А из чего сделан такой вывод? для перечисленной функциональности вполне хватит jet'а или вообще какой-нибудь embedded приблуды. А если большие базы для этого использовать, то под сам лотус ничего не останется. Этот зверек один из самых прожорливых, там и клиент-то такой, что вздрогнешь, а про сервер я вообще молчу.
Ты хоть в глаза-то лотус этот видел?
Короче, не надо на лотус смотреть, лучше зажмуриться.
M>Во вторых подтверждается именно практикой tpc и sap, не говоря уже о практике всех васей пупкиных, которым пришлось писать более-менее серьезное приложение и под версионник, и под блокировочник.
опыт васи, с кривыми ручками меня как-то мало интересует
а вот опыт tpc.org и sap говорит о том, что оракловая модель быстрее, имеет преимущества версионности.
А>>ОК, давай я еще раз носом тыкну ! M>Носом будешь тыкать где-нибудь в другом месте, а здесь держи себя пожалуйста в руках, иначе за тебя это сделают другие..
цитата:
У многих разработчиков выроботолись плохие привычки в отношении транзакций.
[skip]
Это объясняется тем, что в упомянутых СУБД (MSSQL, INFORMIX) блокировки — ценный ресурс, а сеансы, читающие данные, блокируют сеансы изменяющие данные. Пытаясь повысить параллелизм, создатели этих СУБД заставляют разработчиков делать транзакции как можно короче (иногда в ущерб целостности данных).
[skip]
Столкнувшись с задачей изменения большого кол-ва строк программисты обычно пытаются изобрести процедурный способ сделать это в цикле — так, чтоб можно было фиксировать изменения группы строк определенного размера. Я слышал 2 обоснования подобного решения:
— быстрее и эфективнее фиксировать изменения часто с помощью множества небольших транзакций
— недостаточно места в сегментах отката
create table t as select * from all_objects ;
set timing on
update t set object_name=lower(object_name);
00:00:01.12
begin
for x in (select rowid rid, object_name, rownum r from t)
loop
update t set object_name=lower(x.object_name) ;
if (mod(x.r,100)=0) then
commit;
end if;
end loop;
commit;
end;
00:00:05.99
на этом простом примере показано, что частое фиксирование изменений в цикле в 5 раз медленее.
[skip]
Теперь давайте вернемся ко второй причине, связанной с экономичным использованием разработчиком "ограниченого ресурса" (сегмента отката). Это проблема конфигурирования — необходимо предусмотреть достаточно места в сегментах отката для поддержки транзакций требуемого размера. Фиксация в цикле — мало того, что обычно медленнее, это одна из наиболее частых причин возникновения ORA-01555 snapshot too old.
[skip]
в модели многовариантного доступа oracle данные в сегментах отката используются для востановления блоков в том виде, который они имели в начале выполнения оператора или транзакции (в зависимости от уровня изолированности). Если необходимые данные отмены не доступны, выдается сообщение об ошибке ORA-01555 snapshot too old и запрос не выполняется. Так что если вы изменяете считываемую вами таблицу (как в представленом выше анонимном блоке ) то генерируете данные отмены, необходимые для выполнения запроса для согласованного представления изменяемых данных. Если изменения фиксируются, системе разрешается повторно использовать только что занятое место в сегменте отката. Используя его, она стирает данные отката, которые в дальнейшем могут понадобится для выполнения запроса т.е. у вас возникает большая проблема, Оператор SELECT не выполнится и изменения остановятся на пол пути. В результате получится частично завершенная транзакция, и никакого приемлевого способа выполнить ее повторно, как правило, не существует.
[skip]
Подведу итоги: нельзя "съэкономить" место в сегментах отката, фиксируя изменения чаше, — эта информация необходима.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> хм помоему быстрее на Athlon 64 переползут. M>Чего-то я не видел 64 процессорных серверов на атлоне, а на итаниуме их как грязи. M>Пока за Атлон серьезные производители серверов, типа HP, Unisys, ect., не возьмутся то и говорить не о чем..
Сервер IBM eServer 325 на базе AMD Opteron с установленной Oracle 8i позволил повысить производительность weather.com и совершить быстрый и переход на новую платформу без переписывания программного обеспечения.
Компания DaimlerChrysler AG установила новый кластер на базе процессоров AMD Opteron в Техноцентре "Мерседес-Бенц" в Германии
Fujitsu Siemens представляет рабочую cтанцию на базе Opteron
Sun: AMD64 – убийца Itanium
Популярный английский тематический интернет-журнал Computing опубликовал в четверг интервью со Скоттом Макнили (Scott McNealy), председателем совета директоров и исполнительным директором Sun Microsystems, Inc. В числе других вопросов, само собой, были обсуждены и некоторые аспекты касательно созданного недавно союза Sun и AMD.
Директор Sun лишний раз подтвердил, что его компания будет активно использовать Opteron в своих двух-, четырех- и восьмипроцессорных системах, а также упомянул некий «новый многозадачный чип», появление которого планируется уже в следующем квартале. Он рассчитывает достигнуть взаимовыгодного соглашения с AMD, поскольку версия Solaris (разрабатываемая Sun операционная система) для процессоров Xeon удачно портировалась на Opteron без каких-либо значительных изменений. По словам главы нового союзника AMD, компания сделала выбор в пользу Opteron, оставив без внимания Itanium, т.к. его время ушло – «Itanium – архитектура ушедшего тысячелетия». Дело в том, что 64-х битная архитектура Intel требует значительных изменений в коде программ, в особенности, операционных систем – что связано с большими затратами на изменение исходников, перекомпиляцию и сертификацию новой версии ОС. Одним словом, позицию Скотта Макнилли можно охарактеризовать его высказыванием «AMD64 – убийца Itanium».
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Callisto, Вы писали:
C>ИМХО C>плюсы за тот или иной продукт, в данном контексте C>1. К чему больше лежит душа то обычно и пользуют.
ОБЫЧНО используют, то что скажут C>2. Что имеется в наличии или можно быстрее приобрести, или халявнее
Это зависит от проекта если нужно лицинзионный то, это отдельный разговор C>3. Что больше знаешь. Если знаешь MSSQL, а ORACLE не знаешь — что выберешь?
C>а в производительности они, скорее всего, примерно одинаковы.
А С этим в корне не согласен, Oracle намного функциональнее
Здравствуйте, barlock, Вы писали:
C>>а в производительности они, скорее всего, примерно одинаковы.
B> А С этим в корне не согласен, Oracle намного функциональнее
Хм.. Так с чем ты не согласен, с функциональностью или с производительностью?
Здравствуйте, <Аноним>, Вы писали:
А>Не согласен, очень часто из-за разницы идеологий — вылезает разница в производительности.
Ну откровенную-то чушь пороть не надо....
А> статистику в вебе можно было тогда показать только через грязное чтение ... что не приемлимо.
Это не разница в идеологии а просто кривые руки, что вообщем-то должно быть вполне очевидно.
Здравствуйте, Пахом, Вы писали:
П>Сравнение производительности работы Oracle и MS SQL Server, для Вас вообще не должно играть ни какой роли. Разницу в производительности в своих приложениях, я уверен, Вы не заметите.
Это точно. Скажем так, если приложение не очень большое. Если большое, то все зависит от программиста, который может опустить, что одну, то другую БД.
Но вот что-то я плохо представляю MSSQL, который бы смог работать действительно огромными БД. Его внутренний язык так называемый TSQL, если не ошибаюсь, такое убожество, что с ним только одни мучения. Как-то пытался сделать простейшее в запросе SELECT, надо было выбрать данные из одной (всего ОДНОЙ) таблицы, проанализировать таковые и вернуть результат, обыкновенная функция — фигушки.
Для разработчика, программиста, конечно же Oracle дает практически безграничные возможности — поддержка Java, EJB, CORBA. Очень приятно, когда код бизнес-логики на Java, можно полностью (или хотя бы частично) перенести на сервер БД, и использовать без всяких заморочек. Java плюс кросс-платформенность уже есть о чем призадуматься.
Специально написанные продукты разработки для Oracle, очень просты и удобны для написания действительно больших приложений, я имею в виду Oracle Developer Studio, одни из наиболее часто используемых это Oracle Forms, Reports, JDeveloper, Designer (ERP-диаграммы, бизнесс потоки и т.д.) и т.п.
Естественно, если MSSQL сделает столько-же для разработчиков БД, как и Оракл, то будет приятно работать и с ним.
Hе секрет, что rollback надо делать пореже,
Лучше делать почаще commit!
Я программой своей скоро сервер повешу —
У админа пускай голова поболит.
Под крики о кастрации,
В обкуренной прострации,
Как следствие мутации
Рождается в момент
Rollback segment для маленькой,
Для маленькой такой транзакции,
Для скромной такой транзакции
Огромный такой сегмент!
Hе секрет, что rollback — это язва и грыжа,
Геморрой и чуть-чуть гайморит.
Если ты программист, а не ослик бесстыжий —
Лучше делай почаще commit!
Припев.
Hе секрет, что друзьям тоже надо ресурсы,
Hадо память, процессор и диск...
Так что делай commit, а иначе... ты в курсе,
Что rollback — для тебя неоправданный риск.
Здравствуйте, <Аноним>, Вы писали:
M>>DMO — это часть engine сервера. А>в сиквеле такого нет.
А> дайте ссылку что это за DMO. Distributed Management Objects
А>а кто о данных говорил ? речь шла о БД, еще вопросы есть для чего она там ?
По кругу пошли?
Java не часть БД. Не физически (физически я могу БД заставить хоть кофе варить), а логически, она выполняет совершенно другие функции, отличные от тех для которых предназначена БД.
БД — это хранилище данных и хранением занимается SQL, а Java занимается обработкой и то, что Java физически находится примерно там же и может вызывать SQL команды напрямую, никакой роли не играет.
А>уу .. как запущено. опять мимо — xml всего лишь язык и совсем не данные.
Я где-то говорил, что XML — это данные?
Впрочем с xml'ем пусть краеведы из соседнего форума разбираются.
А> реляционные данные можно выдать в формате xml, например оракл так умеет ...
Так xml язык или формат?
Чтобы реляционные данные переделать в любой другой формат и обратно — много ума не надо. Есть соответствующая теоремма, доказанная еще годах в 70х, что это возможно, собственно это одна из вещей, за которые реляционные базы и держат. Но если подходить с точки зрения форматов, то данные, после преобразования, перестают быть реляционными. Ни один оператор реляционной алгебры, без обратного преобразования, к ним применить уже нельзя. Все, баста карапузики.
А>т.е. даже фантазировать не нада
Да, лучше не стоит.
А>опять страшную тайну открою — Xquery задумывалось пускать на реляционные данные ... А>пока славу богу никто в xml данные хранить не догодался.
Это в юмор, наверное надо..
Вообщем пока ни один термин по делу Вами использован не был.
Если желаете продолжить, то дайте пожалуйста определение РСУБД, можно своими словами и можно начать с термина Relation, от этого и будем плясать, иначе разговор получается совершенно беспредметный.
Hello,
> оба! а пацаны то не знают ... > хотя действительно емли задуматся — ну какая разница вызов внешней процедуры или движек субд ? да дурачки они — пару лет потратили на такую херню, которую уже давно вон студенты реализовали. >
Ну, нельзя считать, что основное достижение в Yukon это возможность писать процедуры или функции на C# — это не основное достижение. Главное это то, что сама база данных сильно меняется. А хранимки на .NET это так, ерунда, больше дань моде.
Например, DB2 (можно скачать бета версию) — тоже будет поддержка процедур на .NET языках http://www-106.ibm.com/developerworks/db2/downloads/dotnetbeta/
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, bizhan, Вы писали:
B>Здравствуйте, aston, Вы писали:
B>>>Скажи мне альтернативу формсам?-) A>>Delphi, VFP, PowerBuilder. Тот же .NET
B>VFP и PB не видел, но Дельфи и .NET ты скорее зря привел в качестве примера. B>Формсы рулят по скорости создания надежно работающих приложений. B>А на дельфи и .NET столько всего придется делать, чтобы оно хоть как-то зажило.
"Не надо ничего красть — все уже украдено до нас" (Цитата).
Перефразируя эту фразу (извиняюсь за каламбур) — не надо столько всего писать — все уже написано до вас. И делфи и НЕТ — компонентные среды (готовые гриды, DB-контролы), так что делать будете столко же сколько и в формсах. Плюс к этому можно что-нибудь свое замутить (в плане ГУЯ).
B>Это сразу и было понятно, что ты не в курсе возможностей формсов.
Ну те, что идут с DevSuite9i видел поверхностно, но IMHO — те же яйца — только в профиль по сравнению с теми, что шли с 7.
B>Здесь речь шла о том, что вот есть у меня разработанные 10 лет назад FMX. B>Клиент-сервер и все такое. А заказчик вдруг говорит — хотим тонкого клиента. B>А я ему в ответ — завтра.
В этом ваша ошибка. Надо было потянуть — бабок поболе затребовать за перевод на тонкого клиента.
B>И завтра у меня вся система на тонком клиенте. Вся.
А у нас послезавтра выяснилось — что с браузера ни один отчет толком распечать было нельзя. IE его так раскорячивал.
B>Все формы и все отчеты вне зависимости от их количества. B>Кто так может?-))
За все в этой жизни приходится платить.
B>Павел B>p.s если понимать цели, задачи и возможности, то даже формсы рулят.
В принципе, согласен. Но я упирал не на функциональность средств — а на их реализацию. Руки надо отрывать за такой ГУЙ.
B>А у MS для MSSQL такого нет. B>У них даже репортера своего нет, о чем тут можно разговаривать и что тут можно сравнивать вообще?-)
Да черт с ним, с MSSQL — мне он пабарабану. Я начинал с того, что удивлялся — почему родные Оракловские ГУИ-средства такие кривые. Почему Quest Software может — а сам Oracle — никак.
B>>Это сразу и было понятно, что ты не в курсе возможностей формсов. A>Ну те, что идут с DevSuite9i видел поверхностно, но IMHO — те же яйца — только в профиль по сравнению с теми, что шли с 7.
B>>И завтра у меня вся система на тонком клиенте. Вся. A>А у нас послезавтра выяснилось — что с браузера ни один отчет толком распечать было нельзя. IE его так раскорячивал.
Это на тему яиц Вы бы их попробовали чтоли
Что формс-сервер, что репорт-сервер — разницы никакой. И IE ничего там не сделает.
B>>Здесь речь шла о том, что вот есть у меня разработанные 10 лет назад FMX. B>>Клиент-сервер и все такое. А заказчик вдруг говорит — хотим тонкого клиента. B>>А я ему в ответ — завтра. A>В этом ваша ошибка. Надо было потянуть — бабок поболе затребовать за перевод на тонкого клиента.
Вопросы такие:
1. вы девелопер или менеджер?
2. это ваш перманентный подход по жизни — "потянуть"?
3. поболе — это сколько?
B>>Павел B>>p.s если понимать цели, задачи и возможности, то даже формсы рулят. A>В принципе, согласен. Но я упирал не на функциональность средств — а на их реализацию. Руки надо отрывать за такой ГУЙ.
Давай всех коров поубиваем за то, что мясо подгорает Я же сразу сказал — "готовить не умете"
B>>А у MS для MSSQL такого нет. B>>У них даже репортера своего нет, о чем тут можно разговаривать и что тут можно сравнивать вообще?-) A>Да черт с ним, с MSSQL — мне он пабарабану. Я начинал с того, что удивлялся — почему родные Оракловские ГУИ-средства такие кривые. Почему Quest Software может — а сам Oracle — никак.
Родные Ораклове средства — нормальные.
А Quest — хочу SqlNavigator для сан спарк солярис. Или TOAD
Нету?
Открою большой секрет — большинство профи-админы для оракла работают с sqlplus.
И чем дальше, тем я больше их понимаю.
Здравствуйте, Merle, Вы писали: M>В том, что T-SQL работает только с реляционными данными и по другому не умеет, да и не должен. M>Ява же работает с объектами, и для преобразования реляционных данных в объекты нужен хотя бы минимальный ORM. При этом непосредственно к данным обращается все равно SQL. M>Ровно с тем же успехом все Яву можно использовать на клиенте, а вот SQL от сервера оторвать уже не полчится.
Ну, зерно поинта суть в том, что все-таки T-SQL ежели честно позиционируется как язык для написания BL. Увы, в настоящее время ограничиться только хранением состояния (например реляционной алгеброй) могут себе позволить только академические СУБД. Промышленное производство требует возможности реализовывать поведение в рамках СУБД. Именно это давление привело к появлению зоопарка процедурных расширений SQL. Когда-то даже триггеры были страшной экзотикой .
Причины очевидны — недостатки чистой клиент-серверной модели видны невооруженным глазом.
Отлично, ребята, если ваше приложение на Delphi начинает неприлично распухать — нет проблем, ставтье Middle-tier и все в порядке. "Но я ведь всего лишь хотел сделать так, чтобы при вставке итема в ордер пересчитывалась сумма ордера...". Те производители СУБД, которые встроили поддержку триггеров, резко вырвались вперед — с точки зрения движка, это почти ничего не стоит. Зато пользователю не нужно удваивать стоимость системы путем приобретения среднего слоя. Кроме того, теперь можно учить на один язык меньше.
В настоящее время мы имеем ту же ситуацию. Некоторые производители СУБД встраивают поддержку языков общего назначения, чтобы стать "ближе к народу". Действительно, все эти диалекты SQL со страшной силой сливают языкам общего назначения там, где требуется функциональность м... общего назначения . Несмотря на то, что все то же самое можно реализовать в клиенте/среднем слое, и, как правило, без особой потери производительности, а на крайний случай всегда есть доступ изнутри СУБД к внешнему коду, эта неожиданная мутация сервера хранения представления в сервер реализации поведения является неизбежным следствием тенденций индустрии.
Кстати, заявки MS на этом фронте выглядят очень и очень неплохо. Дело в том, что .NET заранее обложился кастом-метаданными, которые могут позволить объединить лучшие черты оптимизаторов реляционных запросов с оптимизацией языков общего назначения. Теоретически уже сейчас видны намеки на то, каким образом они смогут обеспечить более высокую эффективность применения встроенного CLR кода по сравнению с 3-tier и импортами из DLL (расходы на коммуникацию и "переключение контекста" в расчет не берем — ребята, на практике это фикция. Траблы начинаются ровно в том, что дата-сервер знает всё об особенностях хранения данных, апп-сервер — об особенностях поведения объектов, но пока язык общения между ними ограничен SQL, суммарный результат не будет идеальным. Сервер данных вынужден делать ровно то, что ему говорят, (а мог бы и соптитмизироваться, если бы знал зачем ему это говорят), а апп-сервер вынужден говорить все это (а мог бы соптимизироваться, если бы знал, что там "внизу"))
Я с большим интересом жду выхода MS SQL Server 9.0 final или публикации его результатов на www.tpc.org (whaterver comes first). Там мы посмотрим, чей сахар слаще — джава в Oracle или C# в Yukon
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали:
А>"достать данные по человечески можно только через SQL" — ну это временно, А>вот например Xquery, даже W3C считает вполне человеческим. А>http://www.oracle.com/ru/oramag/december2003/index.html?dev_xquery.html А>думаю скоро воткунт и в оракл и дб2 (если не уже)
А ты погляди кто этот стандарт предложил и догадайся где оно появится первым
Здравствуйте, Аноним, Вы писали:
А>совсем не обязательно тут пересказывать ... достаточно одной ссылки, с указанием где зерно ...
Как хорошо показывает практика, на Вашем примере, без книжки с хорошей теорией одна, и даже десяток, ссылок на зерно не помогают.
A> только умоляю — не на Мерле. я извиняюсь но он порет откровеную чушь (например топик про блокировки II).
От Вас слышать обвинение в чуши несколько странновато...
Что же касается указанного сообщения, то там собственно мысль не моя, а некоего Фила Бернстайна, который, к слову, в мире БД будет по авторететнее того же Тома Кайта.
А>из ваших строк я понял 2 проблемы — дедлог и ресурсы? так ?
Нет, из его строк надо было понять, что неплохо бы пойти и почитать теорию... Или хотя бы понять, как работает любимый Оракл, зачем ему блокировки при такой чУдной версионности, и в каких местах его версионность встает колом, а блокировки не спасают, потому как умеют мало.
А>в OLTP у блокировочника есть преимущество
Сломался !!!
А>, но в реальной жизни очень редко встречается такая идеальная как в тестах задача и тут рульность версионности вылазит во всей красе.
В реальности как раз чистая версионность нервно курит, тот же Оракл при необходимости пользует блокировки, но не очень удачно...
А>версионная модель Юкона вытеснит блокировочную,
Да, надо совсем не знать как и что работает, чтобы говорить такое...
А> также как это роизошло в опен сорсе — posgres, firebird, mysql — я не знаю ни одной бд в опен сорсе блокировочника.
Согласен — это сильный аргумент...
Один клон Оракла, другой чистого версионника IB, а в третьем вообще транзакции толком и не появились..
А>на данный момент как в прочем и много лет до этого оракл всех делает больше чем на 20% на любых тестах,
А> оракл как был 30 лет назад первым (первая РСУБД) так и сейчас.
Вот это сильно!
А ничего, что когда Оракл еще умещался на дискету, ни чуть не менее реляционный DB2 ворочал гигабайты на майнфрейме?
Языком трепать — не мешки ворочить конечно, но меру-то знать надо...
А> девятку они поставили RACом и запихнули всякую ерунду,
Ага, нашли виноватого...
А> поэтому и было там пару процентов отстование,
Ну не пару, а 50...
А> посиотрите что было 5-10 лет назад.
Рулили DB2 и Terradata.
А>ладно чо-то мы серьезные сегодня .. нада передать привет хорошему модератору Мерле
Всегда рад благодарным ценителям..
Здравствуйте, aston, Вы писали:
TK>>Вопрос. Какой смысл вкладывается в слова "Переключение контекста" (в контексте данного обсуждения конечно)?
A>Вопрос обширный (надо цитировать матчасть), но если в 2-х словах, то это использование одного языка в другом без дополнительных телодвижений.
Тут главное — без дополнителоных движений со стороны кого.
Например, если движок БД написан на java, и из него вызывается хранимая процедура на той-же java (все в рамках одной JVM), то тут да — никакого переключения контекста нет. А вот если движок БД написан в native коде какого-то конкретного процессора (оптимизации там и т.п), то тут без переключения контекстов не обойтись (например теже строки — в java это объект, подчиняются требованиям GC и т.п., а как эта строка может физически представляться в БД, это как бог на душу положит — скорее всего хранение из соображений оптимальности).
Конечно, при желании SQL и ту-же java можно максимально объединить, сделать новый язык и т.п. но, это еще не значит, что в этом решении не будет происходить скрытых переключений контекста (перевод данных из одной форму в другую, переход из контекста JVM в native реализацию сервера БД)
A>В гипотетическом C/SQL это могло бы выглядеть так:
Microsoft это делала еще в чертикаком лохматом году. Вот реальный код:
main()
{
EXEC SQL INCLUDE SQLCA;
EXEC SQL BEGIN DECLARE SECTION;
int OrderID; /* Employee ID (from user) */int CustID; /* Retrieved customer ID */char SalesPerson[10] /* Retrieved salesperson name */char Status[6] /* Retrieved order status */
EXEC SQL END DECLARE SECTION;
/* Set up error processing */
EXEC SQL WHENEVER SQLERROR GOTO query_error;
EXEC SQL WHENEVER NOT FOUND GOTO bad_number;
/* Prompt the user for order number */
printf ("Enter order number: ");
scanf ("%d", &OrderID);
/* Execute the SQL query */
EXEC SQL SELECT CustID, SalesPerson, Status
FROM Orders
WHERE OrderID = :OrderID
INTO :CustID, :SalesPerson, :Status;
/* Display the results */
printf ("Customer number: %d\n", CustID);
printf ("Salesperson: %s\n", SalesPerson);
printf ("Status: %s\n", Status);
exit();
query_error:
printf ("SQL error: %ld\n", sqlca->sqlcode);
exit();
bad_number:
printf ("Invalid order number.\n");
exit();
}
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, theOne, Вы писали:
O> Просто по времени, пока microsoft будет делать что-то новое, то Оракл может уже сделает что-нибудь с поддержкой объектов.
Что-то меня очень большие сомнения по этому поводу одолевают...
Пожалуй единственное, что меня действительно серьезно не устраивает в Оракле, так это то, что он уже довольно долгое время вообще не развивается. Если MS свой сервер развивает очень активно, то Оракл вкладывает больше денег в маркетинг, нежели в саму БД. Ядру сервера уже около десяти лет, но ничего принципиально нового в нем с тех пор не появилось и не менялось. Такое впечатление, что Оракл расслабился и решил, что он всегда будет лучшим, ничего для этого не предпринимая, причем это длится уже довольно давно. Возможно, что Оракл и займется принципиальными переделками, но неизвестно, что из этого получится и оптимизьма по этому поводу у меня нет .
Здравствуйте, Serginio1, Вы писали:
S> Интересно на локальных базах можно а на SQL нельзя???
Да и на локальных-то не особо льзя.
S>Если туже таблицу рассматривать как коллекцию данных объекта являющимся одним их его его полей(а не объектов как таковых), то все прекрасно описывается не нужна никакая сериализация, т.к. запись просто считывается в объект итд.
Объект — это не только набор полей. Набор полей — это структура, а объект обладает поведением. И пока не вызовешь метод объекта, что означает набор полей объекта — неизвестно.
S> И никаких потерь (запись можно и не считывать а держать ссылку на нее)
Где держать?
S> Интересно, насколько вышеописанный подход убьет все напрочь ?????
Именно напрочь, вплоть до полной неприменимости в практических задачах.
S> С точки зрения хранилища данных чем SQL отличается от любой локальной БД????
С той, что в клиент-сервере приходится разруливать многопользовательский доступ.
S> Во во а может алгоритмы пересмотреть, если конечно речь не идет о миллиардах записей.
Думаешь OLAP/OLTP системы полные идиоты разрабатывают?
Они над эффективными алгоритмами круглыми сутками головы ломают, и уж в таких системах все вылизано до невозможного состояния.
S>На самом деле очень много поменялось с того времени особенно в железе и нужно применять другие подходы.
На самом деле — не так много как ты думаешь...
S> Не скажи. Применение объектных запросов это уже новая высокоуровневая абстракция,
Да нет там объектных запросов. Сам запрос все равно реляционный, хотя и используется из объекта напрямую..
S> Премущество SQL в краткой записи алгоритма, который затем разбрасывается на элементарные куски,
Преимущество SQL не в этом.
Дело в том, что на данный момент не существует универсального, более-менее эффективного алгоритма отображения любого объекта на реляционную структуру. И пока такового не появится придется работать руками с SQL'ем.
S> а для объектного подхода нужно разрабатывать свой синтаксис.
Он уже давно разработан, читай ODMG (OQL — Object Query Lang..)
S> Только в SQL этого еще очень долго не будет.
Да SQL'ю это и не нужно... С точки зрения объектов SQL — это костыли. Если появится нормальная OODBMS, то об SQL все забудут, как о страшном сне...
Здравствуйте, Serginio1, Вы писали:
S> Размер страницы индекса должен подбираться для оптимальной скорости вставки.
Ну тоже достаточно спорно, от задачи зависит...
S> Ну зачем сразу в память. На диск, все равно файл кэшируется на уровне системы, хотя и ручками можно постранично держать в памяти.
И вот тут-то все достоинства хеш-таблиц дружно присядут. Поскольку по диску придется елозить гораздо больше, чем при B+дереве и в менее предсказуемом режиме, а дисковые операции самые дорогие.
А если еще и про многопользовательскую работу вспомнить — то вообще труба.
S> На самом деле таких ситуаций очень мало, и сколько нужно статистики например для 100 000 товаров, где то прямое чтение всех записей а где то и другой подход.
И ситуаций гораздо больше чем кажется, и усредненные алгоритмы серьезно проигрывают оптимальным. Все-таки БД сейчас не зря такие, какие они есть.
S>Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам.
Ну вот это ты не прав. Выигрыш от правильного использования статистики существенно больше чем издержки на ее своевременное поддержание.
S> Использую Хэш таблицы итд ????
А что, ты хотел движек БД напрямую из хранимок пользовать?
Здравствуйте, Serginio1, Вы писали: S>Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager) S> Ну простым перебором по 50000 это вообще милисекунды.
Нда. То есть никаких планов запроса, кроме прямого перебора, ты предложить не можешь. Насчет милисекунд на 50000... Во-первых, ты не знаешь, как реализован метод IAmountable.Amount(). А я напомню, что у нас нашлось еще и 20 разных его реализаций. Во-вторых, у нас как минимум 5 одновременных R/W транзакций, и 50 R (это я считаю, что 90% времени пользователь тормозит и запросов не отправляет) и требования изоляции еще никто не отменял. Будем ставить блокировки? Вот почему-то блокирующие RDBMS не считают это такой тривиальной задачей, и избегают row-level локов поелику возможно. А у нас тут значит рррррррррррраз за миллисекунды выдали 50000 локов, и тут же отдали. Интересно. S>А если ISecuredObject.AllowsAccess((Context.User as Employee).Manager)==false то вообще бегать.
Этого утверждения я не понял. Ты имеешь в виду то, что некоторые реализации ISecuredObject могут всегда возвращать false из AllowAccess? Да ну! Так не бывает. Внутри какая-то логика сидит. S>>Да ты пока еще ничего не объяснил. Продолжай. Расскажи мне, каким алгоритмом мы будем выполнять запрос. S> Учитывая, что за выборку отвечает некий объект, считывая данные в поле объекта. Все очень просто.
Нда. Или я плохо спрашиваю, или ты просто не имеешь представления о чем говоришь. Некий объект и отвечая — это фигня.
Лирическое отступление: OLTP систему нельзя строить на прямом переборе. Масштабируемость никакая! Почему-то даже в случае структур, т.е. не то что VMT — вообще методов нет, RDBMS занимаются всякой ерундой — статистикой, индексированием... А ты утверждаешь, что отказ от этого ухудшит производительность не более чем в 2 раза... Да нет. Все ухудшится как минимум до N/logN. Это если RDBMS не владеет семантическими данными, типа check constraint Amount<100. Давай оценим, насколько твой способ хуже. Уже при N=50000 логарифм по основнию 128 (пусть у нас столько ключиков в B-tree) даст чуть больше 2. То есть нам потребуется прочитать не более 3 страниц индекса перед тем, как начать сканировать данные. И чем выше селективность предиката, тем лучше будет результат (а это так и есть — как правило, запросы возвращают разумное количество данных). Твой алгоритм будет вынужден честно прокачать 50000/128 = ~390 страниц. Хорошо, предположим отобранные данные занимают еще 10 страниц. Index seek читает 13 страниц, что примерно в 30 раз меньше алгоритма прямого перебора. Неудивительно, что на www.tpc.org не видно и не слышно о результатах ODBMS.
А если ты "неким объектом" называешь тот самый оптимизирующий query evaluator — то не скрывай уж от общественности секрет серебряной пули. Черт с ним, алгоритм построителя плана можешь не рассказывать — расскажи сам план, а?
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Да смысл Хэш таблицы в том, что за 1 вычисление ты находишь смещение нужной записи, в среднем за 1-1.5 обращения если есть коллизии. M>Так тебе надо ее построить в памяти с начала.
Зачем, чем Хэш таблица отличается от обычной таблицы????
Это набор записей, где номер нужной записи получается путем вычисление хэша ключа.
Единственная их проблема это ReHash, когда нужно перестраивать всю таблицу и в зависимости от ее размера это может быть проблемой, но увеличивая каждый раз ее в 2 раза по необходимости или во время профилактики по ночам.
S>> Разговор у нас вначале шел о Кубах и их построении. Я утверждаю, что построение их на Хэш таблицах с последющей сортировкой, даст как минимум 4 кратное ускорение если не больше. M>Ну тут ты совсем неправ. Во первых на таких объемах хеш таблица просто в память не влезет, а во вторых у хеша перед деревом в принципе не такое преимущество — максимум десятки процентов.
Чем Хэш таблица отличается от обычной таблицы????
Почему то тесты показывают обратное. S>> Почему не блокировать так же как и обычные таблицы по строкам, по страницам итд M>Потому что в этом случае нет гарантии, что дедлок не случится.
S>>Абсолютно тот же механизм M>Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок.
С такой же вероятностью как и 2-3 (B-tree). Механизмы блокировки теже. S>> О хешах следует говорить при их применени для первичных ключей, где сортированность вещь не нужная и для построении группировок с последующей сортировкой. M>Как раз там отсортированность очень прогодилась бы. Скажем запрос where ID>5 при обращении к диску в силу отсортиованности данных будет считываьб последовательные страницы, а в случае хеша — из разных частей диска. Что вообщем тоже для перфоманса не подарок.
Ну такой запрос для первичных ключей мало вообще где используется т.к. первичный ключ предназначен для связей, а не использоваание его как побочный эффект.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, <Аноним>, Вы писали:
А>>Вот только Юкона нет и еще пару лет небудет. S>Выходит в конце 2004. Та пребета, которая есть сейчас, уже внушает уважение.
Середина 2005 а Юкона все нет и нет....
Добрый день,
прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql.
Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных.
Желательно бы ссылки на статьи или книги.
ИМХО
плюсы за тот или иной продукт, в данном контексте
1. К чему больше лежит душа то обычно и пользуют.
2. Что имеется в наличии или можно быстрее приобрести, или халявнее
3. Что больше знаешь. Если знаешь MSSQL, а ORACLE не знаешь — что выберешь?
а в производительности они, скорее всего, примерно одинаковы.
Здравствуйте, barlock, Вы писали:
C>>а в производительности они, скорее всего, примерно одинаковы. B>А С этим в корне не согласен, Oracle намного функциональнее
А можно поподробнее? Насколько я знаю, MS SQL — это обыкновенная RDBMS, которую проще сравнивать с InterBase, чем с Oracle, где якобы и объектные базы, и Internet-примочки, и чего только нет. Кому не лень, поделитесь плиз в общих чертах, что же в нем все-таки есть.
[]
S>Лично мне больше нравится Оракл. S>1.При работе с MS SQL у разработчика много головной боли с блокировками.
Ты просто не умеешь их готовить.
S>2.Отсутствие в MS SQL : S> а.древовидные запросы
Есть в Юконе.
S> б.поддержка запросов типа select * from(<любой select>), т.е. во фразе from можно в скобках писать другой select(я пробовал на MS SQL, не получилось..может как-то и можно)
Это ошибка.
S>3.В Oracle 9.2 введен новый тип данных XMLType, очень удобная работа с XML(описывать долго).
Есть в Юконе.
S>4. У Oracle два типа триггеров(на запрос и на строку..у MS SQL только на запрос)
Не правда. В MSSQL отсутствует statement triggers, которые ИМХО, значительно уступают в функционалности простым триггерам в MSSQL.
S>5. У Oracle есть поддержка безопасности на уровне строк(может и MS SQL тоже есть, но пока не видел)
Есть в Юконе.
S>Это, пожалуй, самые весомые аргументы в пользу Oracle.Есть много более "мелких".
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, Smileman, Вы писали:
AS>[]
S>>Лично мне больше нравится Оракл. S>>1.При работе с MS SQL у разработчика много головной боли с блокировками.
AS>Ты просто не умеешь их готовить.
Позиция понятна..вместо того, чтобы честно признаться в наличии проблемы, лучше сказать, что кто-то чего не знает
S>>2.Отсутствие в MS SQL : S>> а.древовидные запросы
AS>Есть в Юконе.
S>> б.поддержка запросов типа select * from(<любой select>), т.е. во фразе from можно в скобках писать другой select(я пробовал на MS SQL, не получилось..может как-то и можно)
AS>Это ошибка.
Это не ошибка..это так называемые internal view
S>>3.В Oracle 9.2 введен новый тип данных XMLType, очень удобная работа с XML(описывать долго).
AS>Есть в Юконе.
S>>5. У Oracle есть поддержка безопасности на уровне строк(может и MS SQL тоже есть, но пока не видел)
AS>Есть в Юконе.
Я рад за сторонников MS SQL... то, что у Оракла было пару лет назад..появилось в пресловутом Юконе только сейчас..теперь у фанатов Микрософт на любой вопрос есть достойный ответ ЮКОН !
Здравствуйте, <Аноним>, Вы писали:
А>Вот только Юкона нет и еще пару лет небудет.
Выходит в конце 2004. Та пребета, которая есть сейчас, уже внушает уважение.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Smileman, Вы писали: AS>>Ты просто не умеешь их готовить. S>Позиция понятна..вместо того, чтобы честно признаться в наличии проблемы, лучше сказать, что кто-то чего не знает
Да нет там никакой проблемы.
S>Это не ошибка..это так называемые internal view
Ошибка то, что они не работают. Давно ужо все работает как часы. S>Я рад за сторонников MS SQL... то, что у Оракла было пару лет назад..появилось в пресловутом Юконе только сейчас..теперь у фанатов Микрософт на любой вопрос есть достойный ответ ЮКОН !
Я посмотрю, где будет Oracle, когда выйдет MS SQL Server 10.0
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
30.12.03 11:07
Оценка:
S>>1.При работе с MS SQL у разработчика много головной боли с блокировками. M>Отчасти это верно, но ты не предсатвляешь какой головной болью может обернуться версионность, если в нее встрять ненароком. Вообще Оракловский механизм concurrency далек от идеала, и хотя является одним из лучших в индустрии, MSSQL'ный ничем ему не уступает... M>Впрочем этот вопрос поистине религиозный и заслуживает отдельного обсуждения.
ну скажем так, статей о том как боротся с блокировками или почему длинные транзакции — зло в оракловой пресе я не видел (видел другие )
ну и судя по тому что в юконе теперь все же сделали снапшот (версионная модель), то очень похоже МС в этом плане уступила. ну нет смысла ограничивать транзакции и боротся с блокировками, если есть версионость — причем эта модель как минимум не медленнее даже на OLTP (см tpc.org)
M>Опять-таки хочу напомнить, что не имеет смысла сравнивать СУБД в целом, оставим это маркетологам у них это заметно лучше получается — их этому учат в конце-концов. У нас же здесь, смею надеяться, техническая конференция, поэтому имеет смысл разбирать отдельные технические решения, и оценивать их эффективность в применении к реальным задачам, а не обобщать, сравнивая теплое с мягким.
Можешь назвать вещи круче реализованные в МС, но не в Оракле ?
Здравствуйте, <Аноним>, Вы писали:
А>ну и судя по тому что в юконе теперь все же сделали снапшот (версионная модель), то очень похоже МС в этом плане уступила.
Нет, не уступила. Версионность в Юконе — это дополнительная функциональность, которую можно отключить если она нафиг не нужна, точнее ее можно включить, если потребуется.
Да и уступать-то нет необходимости, практика показывает, что блокировочники в большинстве задач производительнее, но версионность тоже штука очень и очень полезная. В итоге они совершенно не отказываясь от блокировочности, и даже улучшив ее, добавили еще и версионность, причем на первый взгляд, реализовали ее эффективнее чем Oracle. Но пока реальных тестов и задач не было, поэтому рано говорить на сколько эта реализация версионности будет удачна.
Вообще все классики теории RDBMS еще лет пять назад хором кричали, что максимальной эффективности можно добиться комбинацией версионного и блокировочного механизма в зависимости от условий. Собственно к этой цели MS и идет семимильными шагами.
А>ну нет смысла ограничивать транзакции и боротся с блокировками, если есть версионость — причем эта модель как минимум не медленнее даже на OLTP (см tpc.org)
Версионность на OLTP медленне, и это очень хорошо видно в том числе и на tpc тестах, где даже Oracle 9... с зачатками блокировочника выше десятого места не поднимался.
А>Можешь назвать вещи круче реализованные в МС, но не в Оракле ?
Да, механизм Concurrency Control. Причем я имею ввиду не Юкон, а 2000.
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[5]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
30.12.03 19:03
Оценка:
M>Версионность на OLTP медленне, и это очень хорошо видно в том числе и на tpc тестах, где даже Oracle 9... с зачатками блокировочника выше десятого места не поднимался.
я не улавливаю логики если версионность медленне, чем мы тогда объясним что блокировочник MS в данный момент находится на почетном четвертом месте на tpc.org и вообще где-то в хвосте на тестах SAP ? или типа 10ка у нас теперь не версионник
мы модель меряем или номера ?
А>>Можешь назвать вещи круче реализованные в МС, но не в Оракле ? M>Да, механизм Concurrency Control. Причем я имею ввиду не Юкон, а 2000.
вот тут было бы интересно наконец услышать — какие преимущества ? а то так много говорится а меня так и не просветили
версионник на OLTP занимает первые места, позволяет не ограничивать длину транзакции, на одном сервере получать и отчеты и OLTP, а что дает 2000 ?
Здравствуйте, <Аноним>, Вы писали:
А>я не улавливаю логики если версионность медленне, чем мы тогда объясним что блокировочник MS в данный момент находится на почетном четвертом месте на tpc.org и вообще где-то в хвосте на тестах SAP ?
Во первых давай все-таки сравнивать уже вышедшие сервера, и девятки в tpc-c не видно, что из себя представляет десятка — неизвестно.
Во вторых в SAP тестах MSSQL если где от Оракла и отстает, то совсем не намного.
В третьих, последние 3 года Oracle что-то со своей версионностью не вылезал, так что до следующих тестов MS я бы радоваться победам Оракла поостерегся.
А>вот тут было бы интересно наконец услышать — какие преимущества ? а то так много говорится а меня так и не просветили
Да я тебя уже устал просвещать — бесполезно. Кому надо, тот понял, а ты аргументов просто не воспринимаешь...
А>версионник на OLTP занимает первые места,
Первые места он будет занимать после следующего теста MS.. если сможет.
А> позволяет не ограничивать длину транзакции, на одном сервере
Агащазблин. Ты больше вправляющих мозги статей от Oracle читай. Запусти ка более-менее длинную RW snapshot (а можно даже и не snapshot, RC будет тоже нефигово) транзакцию в нагруженной системе и посмотри, с какой попытки она пройдет (если пройдет), и сколько ресурсов сервера на этот фокус будет положено.
А потом сравни сколько коротких транзакций сиквел за это время сделает.
А>получать и отчеты и OLTP
А что, у блокировочников теперь отчеты и OLTP не проходят? И ничего, что работают они в большинстве случаев эффективнее, чем сделанные в лоб версионные?
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[7]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
31.12.03 00:16
Оценка:
M>В третьих, последние 3 года Oracle что-то со своей версионностью не вылезал, так что до следующих тестов MS я бы радоваться победам Оракла поостерегся.
да я не особо и радуюсь, за это мне не платят
я в который раз хочу намекнуть, что преимущество в скорости — маркетинговая лажа, ни чем не потвержденная, даже накрученые тесты (совершенно сиснтетические), показывют, что нет преимуществ в OLTP у блокировочников, а если и есть, то сьедается нафиг баг-фичами типа эсклоции.
M>Агащазблин. Ты больше вправляющих мозги статей от Oracle читай. Запусти ка более-менее длинную RW snapshot (а можно даже и не snapshot, RC будет тоже нефигово) транзакцию в нагруженной системе и посмотри, с какой попытки она пройдет (если пройдет), и сколько ресурсов сервера на этот фокус будет положено.
речь о сиквере ? тогда честно — не знаю .. про оракл знаю, даже знаю что за ресурсы будут расходоватся — блокировки, ну так если нада их можно на всю базу понатыкать, места на диске от этого меньше не станет. Если требует бизнес правило, то транзакция будет такой длины какой нужно (C) Tom Kyte. Еще роллбэк сегменты сожрут диск, ну и что ?
А>>получать и отчеты и OLTP M>А что, у блокировочников теперь отчеты и OLTP не проходят? И ничего, что работают они в большинстве случаев эффективнее, чем сделанные в лоб версионные?
нет ... не работают, разве что грязное чтение применив ...
или есть другой способ ? вот у меня в сиквеле не получается получить селект по табличке на которой в любой момент времени блокировки висят.
P.S. так я не понял модель — единственое преимущество ? и можно все таки узнать где и как енто преимущество проявляется ?
Мне, например, очень нравится такое преемущество Oracle, как select for update.
И, по моему, в SQL сервере такого нет.
Хотя, я был бы признателен, если мне кто-то скажет, как это проще всего сделать в MS SQL
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Здравствуйте, Аноним, Вы писали:
А>да я не особо и радуюсь, за это мне не платят
Такое ощущение, что все-таки платят..
А>я в который раз хочу намекнуть, что преимущество в скорости — маркетинговая лажа, ни чем не потвержденная,
Это не маркетинговая лажа, а объективная реальность. Подтвержденная и практикой и теорией.
А> даже накрученые тесты (совершенно сиснтетические),
Когда лет пять-шесть назад Оракл там более менее уверенно лидировал тесты были не синтетическими, а самыми настоящими... клева..
А>речь о сиквере ?
Нет, об Оракле.
А>про оракл знаю, даже знаю что за ресурсы будут расходоватся — блокировки, ну так если нада их можно на всю базу понатыкать, места на диске от этого меньше не станет. Если требует бизнес правило, то транзакция будет такой длины какой нужно (C) Tom Kyte. Еще роллбэк сегменты сожрут диск, ну и что ?
Вот сейчас ты открытым текстом рассказал, что даже про Оракл ничего не знаешь.
Фиг с ним, что тебе про MS "рабинович по телефону насвистел", еще можно было бы о чем-то поговорить, но ты даже про Оракл информацию берешь из тех же маркетинговых статей... Так какой смысл тебе чего-то объяснять? Если у меня возникнет желание индукцию с дедукцией через редукцию скрещивать, я к первоисточникам пойду, а здесь — увольте.
А>нет ... не работают, разве что грязное чтение применив ...
Я уже устал десять раз объяснять, интересно — пользуйся поиском.
А>P.S. так я не понял модель — единственое преимущество ?
Нет.
А> и можно все таки узнать где и как енто преимущество проявляется ?
В любом, более менее грамотно написанном приложении.
Здравствуйте, skyline, Вы писали:
S>Здравствуйте, Vasiliy_Krasnokutsky
S>Мне, например, очень нравится такое преемущество Oracle, как select for update. S>И, по моему, в SQL сервере такого нет. S>Хотя, я был бы признателен, если мне кто-то скажет, как это проще всего сделать в MS SQL
Здравствуйте, Merle, Вы писали:
M>В некоторых случаях, когда необходимо, чтобы читающие запросы все-таки блокировали пишущие, и применяется for update.
Да, я это прекрастно понимаю, и знаю, что пишушие запросы должны блокировать читающие только в редких случаях.
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Re[9]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
31.12.03 11:14
Оценка:
M>Это не маркетинговая лажа, а объективная реальность. Подтвержденная и практикой и теорией.
чьей практикой млин ? практика САМЫХ уважаемых организаций tpc.org sap.com грит совсем о другом, или речь о практики Васья Пупкин ?
А>>про оракл знаю, даже знаю что за ресурсы будут расходоватся — блокировки, ну так если нада их можно на всю базу понатыкать, места на диске от этого меньше не станет. Если требует бизнес правило, то транзакция будет такой длины какой нужно (C) Tom Kyte. Еще роллбэк сегменты сожрут диск, ну и что ? M>Вот сейчас ты открытым текстом рассказал, что даже про Оракл ничего не знаешь. M>Фиг с ним, что тебе про MS "рабинович по телефону насвистел", еще можно было бы о чем-то поговорить, но ты даже про Оракл информацию берешь из тех же маркетинговых статей... Так какой смысл тебе чего-то объяснять? Если у меня возникнет желание индукцию с дедукцией через редукцию скрещивать, я к первоисточникам пойду, а здесь — увольте.
ОК, давай я еще раз носом тыкну ! давай так — я заявлю что я получу тормоза если в оракле буду в место одной дилинной транзакции использовать много. ну давай табличка на 10 млн, а нужно проапдейтить 1 млн.
жду просто ответа "нет" и в ответ просто процетирую кусок Tom Kyte
Здравствуйте, Аноним, Вы писали:
А>чьей практикой млин ? практика САМЫХ уважаемых организаций tpc.org sap.com грит совсем о другом, или речь о практики Васья Пупкин ?
Во первых ты определись, tpc самая уважаемая организация или все-таки синтетические тесты?
Во вторых подтверждается именно практикой tpc и sap, не говоря уже о практике всех васей пупкиных, которым пришлось писать более-менее серьезное приложение и под версионник, и под блокировочник.
В третьих, сравнивая модели на sap ссылаться несколько не корректно, так как там реализован свой собственный менеджер транзакций.
А>ОК, давай я еще раз носом тыкну !
Носом будешь тыкать где-нибудь в другом месте, а здесь держи себя пожалуйста в руках, иначе за тебя это сделают другие..
А>давай так — я заявлю что я получу тормоза если в оракле буду в место одной дилинной транзакции использовать много. ну давай табличка на 10 млн, а нужно проапдейтить 1 млн.
Слов нет..
Давай ты лучше сначала с терминологией определишься?
Вот этот вот твой пример не есть "длинная транзакция". То есть ты опять споришь, но не понимаешь о чем речь идет — это нормально?
К слову твой любимый Том Кайт, в данной ситуации, рекомендует принудительно блокировать всю таблицу, потому как иначе Ораклу тяжко придется.
А>жду просто ответа "нет" и в ответ просто процетирую кусок Tom Kyte
Ранее за тобой ни одной, цитаты к месту не наблюдалось. Такое впечатление, что ты выдергиваешь куски из документации, где встречаются знакомые слова и не обращаешь внимания на контекст.
Так что будь внимательнее, когда цитировать соберешься.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Сравнивать Oracle и MSSQL — это то же, что сравнивать Мерседес и Жигули. Оба в принципе могут ездить, только на Мерсе удобнее и быстрее. M>Если уж проводить подобную анологию, тогда это сравнение между Land Cruiser (Oracle) и 325 бэхой... полноприводной (MSSQL). M>И там и там можно ездить с комфортом, по бездорожью на ждипе сподручнее, но ездть почему-то больше приходится по трассе.
По специально для нее (325-ой) построенной — идеально ровной, без ям и кочек, грязи и трамвайных путей. Это я о машине, а не об MSSQL.
IMHO, все же лучше сравнение между Mercedes и BMW — т.е. вопрос религии. Правда, Mercedes то по комплектации явно побогаче будет,хотя и подороже.
А>>Возможности и скорость в Oracle гораздо больше. M>Пффф... [-] M>По возможностям именно RDBMS они абсолютно одинаковы. M>В скорости, для очень широкого класса задачь MSSQL банально быстрее, так что вот так вот откровенно уж не правду говорить не надо.
Не, ну здесь надо говорить — IMHO.
А>>Кроме того Oracle — кросплатформенный. M>Ну вот это да, это есть.
А>>Всех плюсов не перечтешь, пока не поработаешь сам с Ораклом лет несколько. M>И столько же глюков, недоработок и косяков соберешь.
Недоработки есть, а вот глюков и косяков — опять нужно говорить — IMHO.
А>>Но будем откровенны — в MS SQL есть один плюс — он дешевле Оракла, по-моему, раза в два. M>И этот плюс далеко не единственный. MSSQL продуманнее, лаконичнее и проще, как следствее более предсказуемый и надежный.
Опять похоже на божественный голос — типа я всегда прав.
M>Вообще сравнивать DB в отрыве от задачи — мягко говоря не корректно, можно наплести все что угодно, и попробуй докажи, что я не прав. M>О каком-либо тотальном превосходстве какой-нибудь СУБД из тройки лидеров, для более менее широкого класса задач, на данный момент говорить не приходится, по возможностям и производительности они примерно одинаковы, дальше все зависит от специфики и радиуса кривизны рук разработчика. M>Если стоит проблема выбора, то тадо брать ту СУБД, которую лучше знают те, кому придется с ней работать, все остальное — разговоры в пользу бедных.
Браво.
Здравствуйте, aston, Вы писали:
M>>В скорости, для очень широкого класса задачь MSSQL банально быстрее, так что вот так вот откровенно уж не правду говорить не надо. A>Не, ну здесь надо говорить — IMHO.
Не, это не IMHO, это так и есть..
M>>И столько же глюков, недоработок и косяков соберешь. A>Недоработки есть, а вот глюков и косяков — опять нужно говорить — IMHO.
Неа, как раз именно глюков и косяков. Можно спорить по поводу недоработок (что для одного недоработки, то чля другого вполне естественно), но глюки и косяки — факт вполне объективный.
M>>И этот плюс далеко не единственный. MSSQL продуманнее, лаконичнее и проще, как следствее более предсказуемый и надежный. A>Опять похоже на божественный голос — типа я всегда прав.
Не, вот это как раз IMHO.
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[2]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
03.01.04 09:43
Оценка:
П>По моему скромному мнению, из этих двух БД, Вам, надо выбирать ту, с которой именно Вам будет проще разобраться, т.е. по какой БД у Вас больше информации, больше книжек, больше знакомых, знающих эту БД и могущих быстро помочь в случае какого-нибудь небольшого затруднения. П>Сравнение производительности работы Oracle и MS SQL Server, для Вас вообще не должно играть ни какой роли. Разницу в производительности в своих приложениях, я уверен, Вы не заметите.
Не согласен, очень часто из-за разницы идеологий — вылезает разница в производительности.
Например наблюдал проблему — было приложение разработаное не безизвестным васей пупкиным, решили часть базы выложить в веб (статистику), но проблема была в том что приложение блокировало записи (причем целыми страницами) пока висело окно редактирования. статистику в вебе можно было тогда показать только через грязное чтение ... что не приемлимо.
Здравствуйте, <Аноним>, Вы писали:
А>а вот опыт tpc.org и sap говорит о том, что оракловая модель быстрее, имеет преимущества версионности.
Да флаг тебе в руки, особенно учитывая, что опыт tpc и sap говорит как раз обратное.
А>цитата:
А теперь добавь еще бкувально пару слов, каким образов все вышепроцетированное относится к теме разговора...
Ну хоть одну цитату к месту из тебя выжать можно?
Здравствуйте, aston, Вы писали:
A>Пока не поздно, может тему лучше в holy wars. А то щас праздники кончатся, и начнется. Пока все к этому идет.
Я не посту, как только, так сразу...
Здравствуйте, aston, Вы писали:
A>Да здравствует MySQL — самый продуманный, лаконичный, простой и, как следствие, более предсказуемый и надежный сервер баз данных. Притом в скорости он для очень широкого класса задач (известных узкому кругу лиц) банально быстрее (теоретически).
Ну передергивать-то не надо..
Здравствуйте, Merle, Вы писали:
M>Ну хоть одну цитату к месту из тебя выжать можно?
Объясняю почему не к месту была предыдущая цитата:
Во првых, непонятно к чему было приведено упоминание про MSSQL и Informix, они чудно справятся с данной задачей и без выполненя ее в цикле, а одним оператором. Благо с блокировками они справляются гораздо лучше чем Оракл, а сегмента отката там нет по определению.
Во вторых, там не сказано сколько запросов одновременно с выполнением update'а пытались изменить нужные записи. Чем больше таких запросов, тем медленнее будет в оракле выполняться изменение одним оператором и быстрее изменения в цикле, и еще не известно что в конечном итоге окажется выгоднее. Особенно учитывая каким образом Оракл мудрит с RW транзакциями при RC, а при snapshot'е все еще грустнее — там версионник сливает по определению.
И в третьих, эта цитата не имеет никакого отношения к "длинным транзакциям", о коих ты сам речь и завел.
Так что это лишь описание принципов работы с Ораклом, да и то, в определенных условиях. К чему это?
Здравствуйте, aston, Вы писали:
M>>Ну передергивать-то не надо.. A>И я о том же.
Ну и договорились...
С моей точки зрения — "все одинаковые", но моя тонкая душевная организация не выдерживает, когда один из серверов начинают обижать (не важно какой), причем неумело и несколько не по делу...
Здравствуйте, Аноним, Вы писали: А>Например наблюдал проблему — было приложение разработаное не безизвестным васей пупкиным, решили часть базы выложить в веб (статистику), но проблема была в том что приложение блокировало записи (причем целыми страницами) пока висело окно редактирования. статистику в вебе можно было тогда показать только через грязное чтение ... что не приемлимо. А>Gt_
Т.е. из вышесказанного следует, что пиши не безизвестный вася пупкин под другую БД, то с этим приложением все бы было в порядке???
Здравствуйте, theOne, Вы писали:
O>Естественно, если MSSQL сделает столько-же для разработчиков БД, как и Оракл, то будет приятно работать и с ним.
сделает, сделает... можешь быть уверен :))) уже совсем немножко осталось... ждем-с Yukon. то что я одним глазком успел посмотреть и почитать меня вжохновляет :)))
... << RSDN@Home 1.1.2 beta 2 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, theOne, Вы писали:
O>Но вот что-то я плохо представляю MSSQL, который бы смог работать действительно огромными БД.
Смотря что ты понимаешь под действительно огромными...
Скажем так, на мой взгляд в России, на данный момент, в принципе нет задачь такого масштаба, с которыми MSSQL не справился бы. Как не оценивай — будь-то объем, производительность или какое-либо другое требование.
O>Его внутренний язык так называемый TSQL, если не ошибаюсь, такое убожество, что с ним только одни мучения. Как-то пытался сделать простейшее в запросе SELECT, надо было выбрать данные из одной (всего ОДНОЙ) таблицы, проанализировать таковые и вернуть результат, обыкновенная функция — фигушки.
T-SQL это не более чем небольшое расширение стандарта ANSI SQL, и он предназначен исключительно для работы с множествами. Естественно, если пытаться работать с ним, как с обычным языком, то трёхнуться можно. Просто не надо делать на нем вещи для которых он не предназначен.
O>Для разработчика, программиста, конечно же Oracle дает практически безграничные возможности — поддержка Java, EJB, CORBA. Очень приятно, когда код бизнес-логики на Java, можно полностью (или хотя бы частично) перенести на сервер БД, и использовать без всяких заморочек.
Вот здесь-то и лежит главное отличие, текущие версии MSSQL не предназначены для хранения бизнес-логики на сервере. MSSQL — это БД, просто БД, тогда как Оракл становится все больше похож а app-север. В MSSQL бизнес-логика целиком должна быть вынесена на клиента или в средний слой.
В следущей версии это изменится, просто поменяется идеология и из MSSQL сделают практически app-сервер, но я не сказал бы, что текущий подход сильно проигрывает. Причем, если пишется действительно крупное приложение, то и с Ораклом поступают точно так же. Ни одна из его фишек выходящих за рамки хранилища данных не используется.
O>Специально написанные продукты разработки для Oracle, очень просты и удобны для написания действительно больших приложений <...>
Ну тут-то у MS всегда все было в порядке...
Здравствуйте, theOne, Вы писали:
O>Это точно. Скажем так, если приложение не очень большое. Если большое, то все зависит от программиста, который может опустить, что одну, то другую БД.
Полностью согласен.
O>Для разработчика, программиста, конечно же Oracle дает практически безграничные возможности — поддержка Java, EJB, CORBA. Очень приятно, когда код бизнес-логики на Java, можно полностью (или хотя бы частично) перенести на сервер БД, и использовать без всяких заморочек. Java плюс кросс-платформенность уже есть о чем призадуматься.
Для начинающего разработчика приложений БД это не актульно.
Re[4]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
06.01.04 15:36
Оценка:
M>T-SQL это не более чем небольшое расширение стандарта ANSI SQL, и он предназначен исключительно для работы с множествами. Естественно, если пытаться работать с ним, как с обычным языком, то трёхнуться можно. Просто не надо делать на нем вещи для которых он не предназначен.
а можно ссылку на документацию, где о таком говорится ?
M>Вот здесь-то и лежит главное отличие, текущие версии MSSQL не предназначены для хранения бизнес-логики на сервере. MSSQL — это БД, просто БД, тогда как Оракл становится все больше похож а app-север.
можно наконец озвучить какой имеено модуль вдруг сделал оракле апп-сервером ??
может аналические функции, джава, стандартные пакеты ... ?
M>В следущей версии это изменится, просто поменяется идеология и из MSSQL сделают практически app-сервер, но я не сказал бы, что текущий подход сильно проигрывает. Причем, если пишется действительно крупное приложение, то и с Ораклом поступают точно так же. Ни одна из его фишек выходящих за рамки хранилища данных не используется.
ага все на апп сервере переписывают наверно щас опять будет ссылка на авторитетный источник как они эфективно аналитические функции переписали
Здравствуйте, <Аноним>, Вы писали:
M>>T-SQL это не более чем небольшое расширение стандарта ANSI SQL, и он предназначен исключительно для работы с множествами. Естественно, если пытаться работать с ним, как с обычным языком, то трёхнуться можно. Просто не надо делать на нем вещи для которых он не предназначен. А>а можно ссылку на документацию, где о таком говорится ?
О каком о таком? Что ты хочешь в документации найти? Почитай спецификацию ANSI SQL, и чем отличаются языки работы с реляционными данными от всех остальных, для общего развития.
А>можно наконец озвучить какой имеено модуль вдруг сделал оракле апп-сервером ??
При чем тут модуль? Не модуль, а общая идеология.
А>может аналические функции, джава, стандартные пакеты ... ?
О чем ты? Потрудись хотя бы отделить одно от другого и укажи конкретно, что ты имеешь ввиду и что, по твоему мнению, к чему относится.
Ява никаким боком к БД не относится, то есть вообще.
По какому критерию "пакеты" являются "стандартными"?
Давай сначала расскажи, что по твоему мнению, есть БД, и что есть app-сервер?
А>ага все на апп сервере переписывают наверно щас опять будет ссылка на авторитетный источник как они эфективно аналитические функции переписали
Какие функции, о чем ты? Дай пожалуйста определение "аналитической функции" и каким образом это относится к app-серверу или БД, а то опять окажется,ю что ты красивое слово услышал, а о чем оно — весьма слабо себе представляешь...
Здравствуйте, aston, Вы писали:
A>А вот этого не надо. Все, что пишет сам Oracle и при этом ЭТО имеет какой-то GUI — полное убожество . Начиная с SQL+ (даже стрелки не работают). Ну, а Developer Suite — это вообще атас.
Как любят говорить местные апологеты MSSQL — "ты просто не умеешь их готовить"
А Developer Suite действительно атас
Павел
Re[5]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
08.01.04 06:51
Оценка:
Здравствуйте, bizhan, Вы писали:
B>Как любят говорить местные апологеты MSSQL — "ты просто не умеешь их готовить"
Никак не причисляя себя к апологетам MSSQL, хочу сказать, что я просто ел то, что, как мне показалось, слаще редиски(Developer Suite). Причем почему то всем составлющим этой редиски есть более вкусная альтернатива .
А вот то, что пишет Oracle и это НЕ имеет GUI —
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, bizhan, Вы писали:
А>Никак не причисляя себя к апологетам MSSQL, хочу сказать, что я просто ел то, что, как мне показалось, слаще редиски(Developer Suite). Причем почему то всем составлющим этой редиски есть более вкусная альтернатива . А>А вот то, что пишет Oracle и это НЕ имеет GUI —
Не пойму, что все так про нормальный графический интерфейс Оракл цепляются. Программисты MSSQL Server, вы пытаетесь везде разные примочки делать типа как windows -- никому не нужно, но красиво? Неужели цель чтоб у вас признали не только талант программировать, но и талант художественного искусства? Специально, для тех кто любит извращения с интерфейсом юзера, если память не изменяет еще с Forms6i появилось такое понятие как Pluggable Java Component, а начиная с Forms9i JavaBean support mechanism. И все работает хорошо.
Здравствуйте, theOne, Вы писали:
O>Не пойму, что все так про нормальный графический интерфейс Оракл цепляются. Программисты MSSQL Server, вы пытаетесь везде разные примочки делать типа как windows -- никому не нужно, но красиво? Неужели цель чтоб у вас признали не только талант программировать, но и талант художественного искусства? Специально, для тех кто любит извращения с интерфейсом юзера, если память не изменяет еще с Forms6i появилось такое понятие как Pluggable Java Component, а начиная с Forms9i JavaBean support mechanism. И все работает хорошо.
Речь идет не про интерфейс пользователя, а про интерфейс DBA. Как насчет графического представления плана запроса? Насчет графического отображения схемы данных? А 9й еще и график зависимостей ресурсов в транзакциях при дедлоке показывать умеет.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, theOne, Вы писали:
O>Не пойму, что все так про нормальный графический интерфейс Оракл цепляются. Программисты MSSQL Server, вы пытаетесь везде разные примочки делать типа как windows -- никому не нужно, но красиво?
Меня обозвали программистом MSSQL Server — мне обидно.
O>Неужели цель чтоб у вас признали не только талант программировать, но и талант художественного искусства?
Мне нужно, чтоб у них (Oracle) появился талант делать удобно и эргономично. Вот у Quest Software (SQL Navigator, TOAD) этот талант есть. И у Sybase есть (Power Designer).
O>И не надо говорить, что Java имеет плохой UI.
Если не ел ничего слаще редиски, то можно сказать, что он гуд. Вот только тормозной, собака. И правая кнопка мыши не всегда работает. И Tab пашет через раз. Тоже можно сказать и о Ctrl+C, Ctrl+V.
Здравствуйте, Sinclair, Вы писали:
S>Речь идет не про интерфейс пользователя, а про интерфейс DBA. Как насчет графического представления плана запроса? Насчет графического отображения схемы данных? А 9й еще и график зависимостей ресурсов в транзакциях при дедлоке показывать умеет.
Все это есть и реализовано на самом высоком идейном и художественном уровне. Только сделал это не сам Oracle, а Quest Software.
... << RSDN@Home 1.1 beta 1 >>
Re[6]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
08.01.04 19:49
Оценка:
M>О каком о таком? Что ты хочешь в документации найти? Почитай спецификацию ANSI SQL, и чем отличаются языки работы с реляционными данными от всех остальных, для общего развития.
о вот было бы интересно услышать ! только вот где ссылка то ?
а то я вот не образованный считал, что языки для решения определенных задач создаются.
вопрос провакационный — PHP язык для работы с реляционными данными и что будет если я его для работы с транзакциями начну юзать а ?
M>О чем ты? Потрудись хотя бы отделить одно от другого и укажи конкретно, что ты имеешь ввиду и что, по твоему мнению, к чему относится. M>Ява никаким боком к БД не относится, то есть вообще. M>По какому критерию "пакеты" являются "стандартными"? M>Давай сначала расскажи, что по твоему мнению, есть БД, и что есть app-сервер?
боюсь мнение мое тут никому и не нужно ... зачем мне сказки рассказывать — есть докуентация, там четкие определения — и апп сервера и пакетов стандартно поставляющиеся с БД. у вас проблема с переводом ? я помогу вы если что обращайтесь ...
так вот мне не понятно — какие это особенности субд Oracle (а может Sybase & Posgres) вдруг далает его (их) апп сервером. можно огласить весь список ?
А>>ага все на апп сервере переписывают наверно щас опять будет ссылка на авторитетный источник как они эфективно аналитические функции переписали M>Какие функции, о чем ты? Дай пожалуйста определение "аналитической функции" и каким образом это относится к app-серверу или БД, а то опять окажется,ю что ты красивое слово услышал, а о чем оно — весьма слабо себе представляешь...
мда ... ваши познания оракла впечатляют ...
select sum(sal) over (order by depno range 100 preceding) ...
Здравствуйте, <Аноним>, Вы писали:
А>о вот было бы интересно услышать ! только вот где ссылка то ?
Ссылка на что? Спецификация ANSI SQL в гугле, и 92 и 99.
А>а то я вот не образованный считал, что языки для решения определенных задач создаются.
Из предыдущих твоих сообщений можно сделать вывод, что ты считал обратное.
Есть язык SQL, который создан для работы с реляционными данными и оперирует исключительно реляционными понятиями. И попытки с помощю того языка выйти за эти рамки заканчивается плачевно, что вообщем закономерно. Ни для чего другого SQL не предназначен, за то с реляционными данными он справляется лучше всех, за это его и держат.
А>вопрос провакационный — PHP язык для работы с реляционными данными
PHP никакого отношения к реляционным языкам не имеет.
А> и что будет если я его для работы с транзакциями начну юзать а ?
А транзакции здесь причем?
Заканчивай красивые слова не к месту употреблять, уже даже не смешно... Ты мешаешь все понятия в одну кучу из разных областей, совершенно не делая между ними различия.
Ты действительно разницы не понимаешь или просто веселишься?
А>боюсь мнение мое тут никому и не нужно
Мне нужно не твое мнение, а хотя бы примерно составить свое мнение о твоих знаниях, чтобы было понятно каким образом дальше разговор строить. Пока складывается такое впечатление, что ты путаешься даже в базовых терминах.
А>... зачем мне сказки рассказывать — есть докуентация, там четкие определения — и апп сервера и пакетов стандартно поставляющиеся с БД. у вас проблема с переводом ? я помогу вы если что обращайтесь ...
Поблема судя по всему у Вас, с базовыми понятиями и терминологией.
А>так вот мне не понятно — какие это особенности субд Oracle (а может Sybase & Posgres) вдруг далает его (их) апп сервером. можно огласить весь список ?
Возможность написать бизнес логику непосредственно на сервере используя специально предназначаный для этого инструментарий: Java, etc.
А>мда ... ваши познания оракла впечатляют ... А>select sum(sal) over (order by depno range 100 preceding) ...
Так к чему это? Это теперь так определения выглядят? Я так и не увидел определения на аналитическую функцию или ссылки на него.
Здравствуйте, <Аноним>, Вы писали:
А>открою страшную тайну .. ява (java) используется как язык сторед процедур, и не поверишь ... тригеров СУБД
Внимание вопрос знатокам. Для чего он там используется?
Чтобы было проще, и более предметно.
Набросайте мне, если не сложно, небольшую процедуру на яве, которая делает джойн двух абстрактных табличек, желательно с использованием какой-нибудь подсказки оптимизатору, например, чтобы он использовал определенный индекс.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, bizhan, Вы писали:
B>>Как любят говорить местные апологеты MSSQL — "ты просто не умеешь их готовить"
А>Никак не причисляя себя к апологетам MSSQL, хочу сказать, что я просто ел то, что, как мне показалось, слаще редиски(Developer Suite). Причем почему то всем составлющим этой редиски есть более вкусная альтернатива .
Скажи мне альтернативу формсам?-) Я хочу быстро и качественно делать БД-приложения, причем, если мне надо будет переносить его под веб, то чтобы я ничего не делал вообще, а оно само )
А>А вот то, что пишет Oracle и это НЕ имеет GUI —
У них есть штука, которая мне понравилась — Oracle WorkFlow.
Правда это купленная штука, но все равно.
Павел
Re[8]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
09.01.04 07:28
Оценка:
M>Чтобы было проще, и более предметно. M>Набросайте мне, если не сложно, небольшую процедуру на яве, которая делает джойн двух абстрактных табличек, желательно с использованием какой-нибудь подсказки оптимизатору, например, чтобы он использовал определенный индекс.
создается 2 курсора, в цикле оба фетчатся в массивы джавы. далее происходит "джоин" массивов и возвращается 3й массив ... движек SQL используется только для создания курсора, т.к. поросто нет другой конструкции создания курсора. т.е. всю обработку данных (не просто бизнес логику) можно выполнить джавой. вопрос на сколько это эфективно для данной задачи мне не важно.
фокспро/клипер имел только (!) процедурный язык для обработки данных, SQL это все-го лишь один из 3х (+ pl/sql, java) движков в оракле, который ими во всю используется, для решения многих задач.
у меня встречная просба — выдайте мне ANSI SQL92 — для обстрактной таблички работников и зарплаты, нужно получить колонки со средней зарплатой, и сумой, вышестоящих, типа:
1. Иванов 100 100 100
2. Петров 70 85 170
3. Сидоров 60 76 230
p.s. для тех кто непонял — встречаются задачи обработки данных которые решить SQL или невозможно или сложно.
Gt_
Re[8]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
09.01.04 08:20
Оценка:
А>>вопрос провакационный — PHP язык для работы с реляционными данными M>PHP никакого отношения к реляционным языкам не имеет.
А>> и что будет если я его для работы с транзакциями начну юзать а ? M>А транзакции здесь причем? M>Заканчивай красивые слова не к месту употреблять, уже даже не смешно... Ты мешаешь все понятия в одну кучу из разных областей, совершенно не делая между ними различия. M>Ты действительно разницы не понимаешь или просто веселишься?
веселюсь
опять же боюсь ты не поверишь но пхп уже две субд воткнули как язык сторед процедур и тригеров — Posgres и MySql 5.0
PHP (Personal Homepage Processor) предназначался для лобания страничек, а не "для работы с реляционными данными" ну и что ?
да чихать я хотел для чего язык создавался — важно какие проблемы и на сколько эфективно я смогу решить с помощью языка. к стате например процедурным языком фокспро когда-то было эфективней джойнить чем юзать их ущербный SQL движек.
SQL один из многих языков для обработки данных, просто от лучше всех подходит для большинства задач!
А>>боюсь мнение мое тут никому и не нужно M>Мне нужно не твое мнение, а хотя бы примерно составить свое мнение о твоих знаниях, чтобы было понятно каким образом дальше разговор строить. Пока складывается такое впечатление, что ты путаешься даже в базовых терминах.
постить сюда msdn и оракловые недосуг
M>Возможность написать бизнес логику непосредственно на сервере используя специально предназначаный для этого инструментарий: Java, etc.
чо-то непонял этой возможности для T-SQL нет ? или инстрементария нет ?
ну про сиквел я не знаю, зато знаю про Posgres и Sybase — там есть инструментарии, есть языки, причем у обоих есть несколько (у Sybase диалекты, у Posgres pgSQL, pgPL/SQL, pgPHP), знаю люди на сайбэзе пишут бухгалтерию, т.е. обсалютно вся логика на сервере — так что это теперь это апп-сервер докучи ?
А>>мда ... ваши познания оракла впечатляют ... А>>select sum(sal) over (order by depno range 100 preceding) ... M>Так к чему это? Это теперь так определения выглядят? Я так и не увидел определения на аналитическую функцию или ссылки на него.
Здравствуйте, Victor Repetsky, Вы писали:
VR>Здравствуйте, Merle, Вы писали:
VR>Это задача не для Java, конечно, здесь один SQL. VR>Тем не менее задач которые решает Java в хранимых процедурах и тригерах не так уж мало. Например в тригере может понадобится VR>-зашифровать или проанализировать данные ипользуюя какую-либо существующую библиотеку VR>-открыть сетевое соединение (хоть сокеты, хоть веб-сервисы) и сообщить куда следует VR>-соконнектиться и что-то сделать в другой базе (например из Oracle в Interbase)
Полностью согласен, с одним добавлением: все эти операции выполняются в десятки раз быстрее на яве, чем такое же на pl/sql.
Здравствуйте, aston, Вы писали:
A>Ну это да, есть такое. Но, IMHO, писать одно и то же приложение как под Win, так и под Web — это сознательно ограничивать себя убогими средствами Web. Все таки в системе должен быть презентативный слой — один — с качественным ГУИ — для Win. Другой — с убогим — для Web.
Почему убогим? Ты наверное не видел, что можно делать на Forms. Никакого отличия, разве, что клиент с качественным UI грузится в окне браузера. И причем это совсем не обязательно. Можно и в отдельное окно все вывести. Слышал наверное о таких понятиях как "Апплеты"?
Здравствуйте, Victor Repetsky, Вы писали:
VR>Это задача не для Java, конечно, здесь один SQL.
Что и требовалось доказать..
VR>Тем не менее задач которые решает Java в хранимых процедурах и тригерах не так уж мало. Например в тригере может понадобится VR>-зашифровать или проанализировать данные ипользуюя какую-либо существующую библиотеку VR>-открыть сетевое соединение (хоть сокеты, хоть веб-сервисы) и сообщить куда следует VR>-соконнектиться и что-то сделать в другой базе (например из Oracle в Interbase)
Естественно может, но это у же имеет мало отношения к хранению и доступу к данным, чем и занимается SQL. Более того, приложение можно спроектировать таким образом, что эта функциональность в триггере или хп. не требуется, а выносится на клиента или в средний слой, причем без потери эффективности.
Таким образом Ява — это язык описания бизнес логики, а не логики хранения реляционных данных, и непосредственно к БД имеет мало отношения.
Здравствуйте, <Аноним>, Вы писали:
А>веселюсь
Хм.. Как-то не очень удачно получается.
А>опять же боюсь ты не поверишь но пхп уже две субд воткнули как язык сторед процедур и тригеров — Posgres и MySql 5.0
Ага, как замену SQL? Не смешите мои тапочки.
А>PHP (Personal Homepage Processor) предназначался для лобания страничек, а не "для работы с реляционными данными" ну и что ?
Ну вот и лабайте на нем странички.
А>да чихать я хотел для чего язык создавался — важно какие проблемы и на сколько эфективно я смогу решить с помощью языка.
О! Так как мне с помошью ПХП джоин двух таблиц сделать? Или запись в БД вставить? Только эффективно.
А>SQL один из многих языков для обработки данных, просто от лучше всех подходит для большинства задач!
Не обработки. Обработка — это бизнес логика. SQL — это хранение.
А>чо-то непонял этой возможности для T-SQL нет ? или инстрементария нет ?
Я могу повторить еще раз, что T-SQL не предназначен для описания бизнес-логики. Как вообщем и стандарт SQL и Оракловский SQL и любой другой диалект SQL'я. Он просто не для этого создавался.
MSSQL предполагает реализацию БЛ на клиенте, Оракл — на сервере с помощю Явы и всего остального. И реализация БЛ выходит за рамки БД, это уже не сервер хранения, а сервер обработки данных получается.
А>ну про сиквел я не знаю, зато знаю про Posgres и Sybase — там есть инструментарии, есть языки, причем у обоих есть несколько (у Sybase диалекты, у Posgres pgSQL, pgPL/SQL, pgPHP), знаю люди на сайбэзе пишут бухгалтерию, т.е. обсалютно вся логика на сервере — так что это теперь это апп-сервер докучи ?
Я еще я знаю, есть люди, которые микроскопом гвозди заколачивают, и довольно ловко.
А>ну как же так ? на днях это как стандарт ANSI SQL утвердят, а вы еще не слышали
Не слышал? Я не слышал, что Вы имеете ввиду под аналитическими функциями.
А>http://otn.oracle.com/products/bi/pdf/o9i_analyticsql_twp.pdf
А, то есть утверждается, что в MSSQL этого нет? Увы, есть и уже довольно давно.
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[10]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
09.01.04 13:02
Оценка:
А>>создается 2 курсора, в цикле оба фетчатся в массивы джавы. далее происходит "джоин" массивов и возвращается 3й массив ... движек SQL используется только для создания курсора, т.к. поросто нет другой конструкции создания курсора. т.е. всю обработку данных (не просто бизнес логику) можно выполнить джавой. вопрос на сколько это эфективно для данной задачи мне не важно. M>Используя подобную логику я могу утверждать, что в MSSQL'е работа через DMO — это аналог Оракловской Явы и даже круче, там вообще ни одной SQL команды не встречается.
вы меня удивляете с каждым постом неужели вы не в курсе что jvm в оракле встроена и выполняется на сервере как его процесс, в памяти сервера (SGA), а это значит, что не происходит (практически) переключений контескта в ОС.
В M$ такого нет, и появится разве что в Юконе.
M>Ява — это инструмент работы с бизнес логикой, а SQL с логикой хранения. И Бизнес логика в задачи БД не входит.
мда ... сурьезная заявка на победу, тогда давайте разберемся, что же у нас логика а что субд.
1. что такое репликация? входит не входит она в задачи субд, если да то каким местом (забегая в перед скажу что реализована она на pl/sql)
2. стандартные функции для работы с сетью и майлами (UTL_TCP, UTL_SMTP) (забегая в перед скажу что реализована она на java)
3. при накладывания патча 9.2.0.4 на сервере выполняется джава процедура, которая корежит системные словари БД.
M>И в итоге любое, более менее сложное приложение превращается в дикую смесь из этих трех языков, в которой без поллитры не разгребешся. Потому как достать данные по человечески можно только через SQL, чем движек БД и занимается и на этом БД заканчивается. А дальше начинается шаманство с PL/SQL'ем и Явой — зато все на сервере.
А>>у меня встречная просба — выдайте мне ANSI SQL92 — для обстрактной таблички работников и зарплаты, нужно получить колонки со средней зарплатой, и сумой, вышестоящих, типа: А>>1. Иванов 100 100 100 А>>2. Петров 70 85 170 А>>3. Сидоров 60 76 230 M>А каким образом организованы эти абстрактные таблички работников и зарплаты?
1. Иванов 100
2. Петров 70
3. Сидоров 60
тогда в результе 3 колонка — среднее, 4я — сумма, всех вышестоящих. M>В любом случае операторов SUM, AVG и GROUP BY никто не отменял.
sum и avg не спасут
в сиквеле нет аналитических функций.
Gt_
Re[11]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
09.01.04 13:41
Оценка:
Здравствуйте, Аноним, Вы писали:
А>1. Иванов 100 А>2. Петров 70 А>3. Сидоров 60
select
w1.name,
w1.salary,
w2.sum,
w2.sum / w2.count avg
from
workers w1,
(
select w1.name, sum(w2.salary) sum, count(w2.name) count
from workers w1, workers w2
where w2.salary >= w1.salary
group by w1.name
) w2
where
w1.name = w2.name
Здравствуйте, theOne, Вы писали:
O>Почему убогим? Ты наверное не видел, что можно делать на Forms. Никакого отличия, разве, что клиент с качественным UI грузится в окне браузера. И причем это совсем не обязательно. Можно и в отдельное окно все вывести. Слышал наверное о таких понятиях как "Апплеты"?
Слышал, слышал. Они еще сами скачиваются на клиентов. А еще я слышал понятие "ActiveX в HTML-страницах". Только по вполне понятным причинам в диком виде эти вещи не используются. А как тогда сделать нормальный GUI в Web-страницах без Java-апплетов и ActiveX-контролов?.
Здравствуйте, Merle, Вы писали:
M>Чтобы было проще, и более предметно. M>Набросайте мне, если не сложно, небольшую процедуру на яве, которая делает джойн двух абстрактных табличек, желательно с использованием какой-нибудь подсказки оптимизатору, например, чтобы он использовал определенный индекс.
Зря вы так.
В Оракловской Яве есть такая штука SQLJ. Так что тут проблем не будет точно. Примерный код
.import java.sql.*;
/**
This is what we have to do in SQLJ
**/public class SimpleDemoSQLJ // line 6
{
//TO DO: make a main that calls thispublic Address getEmployeeAddress(int empno) // line 10throws SQLException
{
Address addr; // line 13
#sql { SELECT office_addr INTO :addr FROM employees
WHERE empnumber = :empno };
return addr;
}
// line 18public Address updateAddress(Address addr)
throws SQLException
{
#sql addr = { VALUES(UPDATE_ADDRESS(:addr)) }; // line 22return addr;
}
}
Здравствуйте, <Аноним>, Вы писали:
А>вы меня удивляете с каждым постом
Надеюсь, что открываю глаза на реальное положение вещей.
А> неужели вы не в курсе что jvm в оракле встроена и выполняется на сервере как его процесс, в памяти сервера (SGA), а это значит, что не происходит (практически) переключений контескта в ОС.
А какое отношение переключение контекста имеет к обсуждаемой теме?
А>В M$ такого нет, и появится разве что в Юконе.
DMO — это часть engine сервера.
А> тогда давайте разберемся, что же у нас логика а что субд.
Давно пора.
А>2. стандартные функции для работы с сетью и майлами (UTL_TCP, UTL_SMTP) (забегая в перед скажу что реализована она на java)
Это не есть логика работы с реляционными данными.
А>3. при накладывания патча 9.2.0.4 на сервере выполняется джава процедура, которая корежит системные словари БД.
При этом работа непосредственно с реляционными данным выполняется все-равно через SQL, а на Jave уже корежение этих данных в соответствии с заложенной логикой.
А>"достать данные по человечески можно только через SQL" — ну это временно, А>вот например Xquery, даже W3C считает вполне человеческим.
Напоминаю, что речь идет о реляционных данных, а XML назвать реляционным нельзя, даже обладая очень большой фантазией.
M>>А каким образом организованы эти абстрактные таблички работников и зарплаты? А>1. Иванов 100 А>2. Петров 70 А>3. Сидоров 60 А>тогда в результе 3 колонка — среднее, 4я — сумма, всех вышестоящих.
Например так:
SELECT ID, Name, Q,
(SELECT avg(Q) FROM tbl WHERE ID<=t.ID) [AVG],
(SELECT sum(Q) FROM tbl WHERE ID<=t.ID) [SUM]
FROM tbl as t ORDER BY ID
К слову, в SQL нет понтия "вышестоящий", так что задача в терминах SQL не корректна.
А>в сиквеле нет аналитических функций.
Там есть целый сервер — Analysis Services.
Здравствуйте, aston, Вы писали:
A>Зря вы так. A>В Оракловской Яве есть такая штука SQLJ. Так что тут проблем не будет точно. Примерный код
<...>
{ SELECT office_addr INTO :addr FROM employees
WHERE empnumber = :empno }
Вот это тоже Ява? Так что не зря..
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[12]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
09.01.04 19:00
Оценка:
А>>В M$ такого нет, и появится разве что в Юконе. M>DMO — это часть engine сервера.
в сиквеле такого нет. дайте ссылку что это за DMO.
А>> тогда давайте разберемся, что же у нас логика а что субд. M>Давно пора.
А>>2. стандартные функции для работы с сетью и майлами (UTL_TCP, UTL_SMTP) (забегая в перед скажу что реализована она на java) M>Это не есть логика работы с реляционными данными.
А>>3. при накладывания патча 9.2.0.4 на сервере выполняется джава процедура, которая корежит системные словари БД. M>При этом работа непосредственно с реляционными данным выполняется все-равно через SQL, а на Jave уже корежение этих данных в соответствии с заложенной логикой.
M>Ява никаким боком к БД не относится, то есть вообще. А>открою страшную тайну .. ява (java) используется как язык сторед процедур, и не поверишь ... тригеров СУБД M> Внимание вопрос знатокам. Для чего он там используется?
а кто о данных говорил ? речь шла о БД, еще вопросы есть для чего она там ?
А>>"достать данные по человечески можно только через SQL" — ну это временно, А>>вот например Xquery, даже W3C считает вполне человеческим. M>Напоминаю, что речь идет о реляционных данных, а XML назвать реляционным нельзя, даже обладая очень большой фантазией.
уу .. как запущено. опять мимо — xml всего лишь язык и совсем не данные. реляционные данные можно выдать в формате xml, например оракл так умеет ... т.е. даже фантазировать не нада
опять страшную тайну открою — Xquery задумывалось пускать на реляционные данные ... пока славу богу никто в xml данные хранить не догодался.
А>>в сиквеле нет аналитических функций. M>Там есть целый сервер — Analysis Services.
точно созвучно
а я знаю еще одно слово с которым созвучно
Hello, > > вы меня удивляете с каждым постом неужели вы не в курсе что jvm в оракле встроена и выполняется на сервере как его процесс, в памяти сервера (SGA), а это значит, что не происходит (практически) переключений контескта в ОС. > В M$ такого нет, и появится разве что в Юконе. >
Добавить возможности Java или CLR к SQL Server это не так уж и сложною.
M$ это еще не пуп земли. Да, они делают очень много софта, но еще больше отдается на откуп сторонним разработчикам.
Например http://www.turtlenecksoftware.com/ — пишем хранимые процедуры на C#, не дожидаясь Yukon
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[12]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
10.01.04 12:44
Оценка:
TK>Добавить возможности Java или CLR к SQL Server это не так уж и сложною. TK>M$ это еще не пуп земли. Да, они делают очень много софта, но еще больше отдается на откуп сторонним разработчикам. TK>Например http://www.turtlenecksoftware.com/ — пишем хранимые процедуры на C#, не дожидаясь Yukon
оба! а пацаны то не знают ...
хотя действительно емли задуматся — ну какая разница вызов внешней процедуры или движек субд ? да дурачки они — пару лет потратили на такую херню, которую уже давно вон студенты реализовали.
Здравствуйте, Smileman, Вы писали:
S>>>б.поддержка запросов типа select * from(<любой select>), M>>В ANSI SQL это называется derived table, в MSSQL есть чуть-ли не с самого начала — замечательным образом работает. S>У меня на MS SQL 2000 не работает..это факт..много раз проверял..может, в синтаксисе ошибся... S>но запрос select count(*) from(select * from <имя_таблицы>) не работает
MS SQL штука такая, что на уговоры поддается плохо. Если SQL запрос написан с ошибкой в синтаксисе, то сколько его не выполняй — правильным он не станет. Тут нужно документацию читать.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[14]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
10.01.04 16:05
Оценка:
TK>Ну, нельзя считать, что основное достижение в Yukon это возможность писать процедуры или функции на C# — это не основное достижение. Главное это то, что сама база данных сильно меняется. А хранимки на .NET это так, ерунда, больше дань моде. TK>Например, DB2 (можно скачать бета версию) — тоже будет поддержка процедур на .NET языках http://www-106.ibm.com/developerworks/db2/downloads/dotnetbeta/
мда впечатляет провайдер для внешней дллены ... вот только несколько смущает что такое есть еще у Posgres, Sybase и еще с десяток субд ...
тут ниже был линк на Юкон, если действительно интересно плз прочтите почему CLI воткнули в субд
Здравствуйте, Smileman, Вы писали:
M>>Здравствуйте, Smileman, Вы писали:
Начну с конца, если позволите.
S>Опять одни лишь слова.. S>В общем, уважаемый Merle, Вы демагог. Прочем, неплохо умеющий подбирать слова и строить фразы.
Спасибо конечно за комплимент, но вопрос изначально, на мой взгляд, не подразумевал какой-либо конкретики и прежде чем нападать, было бы не плохо по четче сформулировать свои желания.
Я ровно с теми же притензиями могу "проанализировать" Ваше первоначальное сообщение. (Конкретный пример головной боли с блокировками, etc.) Но не думаю что стоит залезать в окончательный оффтопик, попрошу лишь в дальнейшем быть более сдержанным в оценках.
S>Что значит "встрять ненароком" ? Прошу конкретный пример.
Запросто. Пользуемся поиском по этому форуму и находим:
Write Skew: http://www.rsdn.ru/Forum/?mid=386155
Не зная об этой проблеме и понадеясь, что указание IL Serilizability в Оракле гарантировано избавляет от проблем упорядочености, можно потом долго несогласованную базу приводить в порядок и концы искать.
И этот феномен не единственный — это особенность версионного snapshot.
M>>Вообще Оракловский механизм concurrency далек от идеала S>опять же не вижу примера..одна пустая фраза
Пользуемся опять поиском по форуму и находим: http://www.rsdn.ru/Forum/Message.aspx?mid=372904&only=1
M>>, и хотя является одним из лучших в индустрии, MSSQL'ный ничем ему не уступает... S>опять же похвалить оракл и не забыть MS SQL
Как не сложно понять это мое IMHO сформироваванное на личном опыте работы и мнении людей, к чьим словам я иногда прислушиваюсь, в силу неизмеримо бОльшего опыта и знаний, чем те которыми я обладаю на данный момент.
S>Т.е очевидно, что в предыдущем абзаце ничего конкретного сказано не было..все пустые фразы "ненароком, далек от идеала,ничем не уступает, ты не представляешь".
Как, впрочем, и в Вашем сообщении, поэтому я счел для себя возможным ответить в таком же ключе.
M>>Это так называемый syntactic shugar — таже самая функциональность делается руками причем заметно эффективнее. S>Это вероятнее всего было прочитано в статье от Микрософта из серии...
Вероятнее всего Вы ошибаетесь. Это было проверено на личном опыте и неоднократно.
S>сомневаюсь, что можно это сделать быстрее
Напрасно. На большинстве задачь реализация дерева через транзитивное замыкание с помощю двух таблиц, работает заметно эффективнее.
M>>В ANSI SQL это называется derived table, в MSSQL есть чуть-ли не с самого начала — замечательным образом работает. S>У меня на MS SQL 2000 не работает..это факт..много раз проверял..может, в синтаксисе ошибся... S>но запрос select count(*) from(select * from <имя_таблицы>) не работает
Да, именно синтаксически. В стандарте ANSI SQL четко прописано, что derived table надо указывать с алиасом в обязательном порядке, и MSSQL, в данном случае, строго следует требованиям стандарта. Чтобы запрос заработал его надо переписать вот так:
select count(*) from(select * from <имя_таблицы>) as alias
M>>А к RDBMS это каким боком? Впрочем поддержка xml — это опять-таки отдельная история. S>Хоть что-то но ответить надо...
А что Вы ожидали? Ответтье пожалуйста, каким образом xml относится к RDBMS и мы обсудим успехи Оракла на этом фронте.
S>>>4. У Oracle два типа триггеров(на запрос и на строку..у MS SQL только на запрос) M>>Нет, это не так. Просто триггеры в MSSQL, так же как и сам SQL предназначены для работы с множествами, что вообщем идеологически правильнее, логичнее, функиональнее и в конечном итоге эффективнее. S>Опять не ясно. И опять одни лишь слова <...>
Здесь все слова.
S>Триггеры прежде всего направлены для реагирования на события..связь триггером и множеств как-то не очень ясна.
Прежде всего триггеры — часть реляционного механизма работы с данными, и весь этот механизм предназначен для работы с множествами. Поэтому было бы не плохо, чтобы триггеры не выбивались из общей идеологии, что и происходит в MS. Триггер срабатывающий на каждую вставку вырождает вставку нескольких значений в курсор, что пагубно сказывается на производительности.
S>Опять же ничего не сказано конкретного...фразы "элементарно..при желании" уже обязательны.
Какой конкретики Вы здесь ждете? Это действительно без особых усилий реализуется через view, совершенно стандартный паттерн известный долгие годы и не моя вина, что Вы об этом не знаете.
S>Опять одни лишь слова.. S>В общем, уважаемый Merle, Вы демагог. Прочем, неплохо умеющий подбирать слова и строить фразы.
Самое смешное, что время от времени приходится защищать и Оракл, от подобных же необоснованных нападок, проистекающих просто от недостаточного знания предмета спора.
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[14]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
10.01.04 18:28
Оценка:
M>>>DMO — это часть engine сервера. А>>в сиквеле такого нет. M>
А>> дайте ссылку что это за DMO. M>Distributed Management Objects
да действительно потрясающая технолгия — странно что ее никто не использует, а то в десятку субд такое есть а они все пытаются интегрировать в субд, молодые и зеленые наверно
А>>а кто о данных говорил ? речь шла о БД, еще вопросы есть для чего она там ? M>По кругу пошли? M>Java не часть БД. Не физически (физически я могу БД заставить хоть кофе варить), а логически, она выполняет совершенно другие функции, отличные от тех для которых предназначена БД. M>БД — это хранилище данных и хранением занимается SQL, а Java занимается обработкой и то, что Java физически находится примерно там же и может вызывать SQL команды напрямую, никакой роли не играет.
чето я устал уже огорчать ... если вы чего-то не знаете не стоит об этом громогласно заявлять, а я то с юмором отнесусь, а вот дети ж верят
стандарт ANSI SQLJ — функции джава в SQL запросах. http://www.osp.ru/os/1999/09-10/061.htm
а теперь представте такое запускается из внешней длл, в своем процессе, памати каждый раз переключая контекст в ОС ... хотя на 2-х юзерах думаю вполне
M>Чтобы реляционные данные переделать в любой другой формат и обратно — много ума не надо. Есть соответствующая теоремма, доказанная еще годах в 70х, что это возможно, собственно это одна из вещей, за которые реляционные базы и держат. Но если подходить с точки зрения форматов, то данные, после преобразования, перестают быть реляционными. Ни один оператор реляционной алгебры, без обратного преобразования, к ним применить уже нельзя. Все, баста карапузики.
их никто не "переделает" ... незачем, 100гб так просто и не переделаешь — речь о языке запросов Xquery, клиент шлет в РСУБД запрос Xquery, РСУБД (оракл) возвращает клиенту, курсор (рекордсет) или xml. чо там клиент с этим делает субд уже не беспокоит ... итак есть РСУБД нет SQL, но все эффективно, просто другой язык запросов, дальше лениво читайте oracle xml db, начинай отсюда http://www.oracle.com/ru/oramag/augsept2003/index.html?dev_xml.html
M>Вообщем пока ни один термин по делу Вами использован не был. M>Если желаете продолжить, то дайте пожалуйста определение РСУБД, можно своими словами и можно начать с термина Relation, от этого и будем плясать, иначе разговор получается совершенно беспредметный.
да ... не получился можно закончить
зато весело было, особенно класно с аналитическими функциями anlytics services.
p.s. рекомендую все же посмотреть другие субд и чуть-чуть задуматся почему они это сделали так, почему jvm ораклу пришлось все переписать и зачем у mysql транзакции — фича таблиц
Здравствуйте, aston, Вы писали:
A>Смотрим начальный пост:
Это не изначальный..
A>Полезно, когда возможностей процедурного языка PL/SQL не хватает и надо использовать объектную модель с наследованием и прочей чухней.
Все дело в том, что объектная модель, сама по себе, выходит за рамки РСУБД. То есть непосредственно от реляционного хранилища данных требовать умения работы с бизнес-логикой несколько не корректно.
A> Так что Java является полноценным участником БД и рассматривать ее как какую-то примочку, не относящуюся к БД — не нужно.
Физически да, но логически Ява обеспечивает совсем другой функционал, мало связанный непосредственно с хранением данных. И поскольку Оракл предоставляет этот функционал, то он считается не чисто БД, а почти сервером приложений, в отличии от MSSQL, который просто БД без высокоуровневых заморочек.
A>Интересно, как в Yukon будут писаться SP на шарпе. Надеюсь, так:
Немного не так, но переключения контекста тоже не происходит. Впрочем раньше времени говорить не буду, пока еще руки не дошли.
Здравствуйте, <Аноним>, Вы писали:
А>да действительно потрясающая технолгия — странно что ее никто не использует, а то в десятку субд такое есть а они все пытаются интегрировать в субд, молодые и зеленые наверно
Во первых используют, весь EM через это дело работает.
А во вторых забить на эффективность не я предложил, так что ирония здесь не уместна.
А>если вы чего-то не знаете не стоит об этом громогласно заявлять
О!
А>а я то с юмором отнесусь, а вот дети ж верят
Об чем и речь, подобная святая вера в маркетинг, пагубно влияет на неокрепшие умы. Посему и приходится спорить, а то давно бы бросил.
А> итак есть РСУБД нет SQL, но все эффективно, просто другой язык запросов, дальше лениво читайте oracle xml db, начинай отсюда
Удивительно, но Вы ухитряетесь в двух строчках изложить то, чего даже разработчики Оракла в свое творение не вкладывали.
Ну нельзя так в терминах путаться и так не к месту их употреблять.
А>да ... не получился можно закончить
Так я и думал.
А>p.s. рекомендую все же посмотреть другие субд и чуть-чуть задуматся почему они это сделали так, почему jvm ораклу пришлось все переписать и зачем у mysql транзакции — фича таблиц
Рекомендую впредь, при употреблении терминов, пояснять их смысл или приводить соответствующую ссылку, так как Ваша трактовка, в подавляющем большинстве случаев, отличается от общепринятой.
А так же, для общего развития, рекомендую почитать академическую литературу, не завязанную на какой-то конкретный сервер, возможно многое станет понятным.
Здравствуйте, Merle, Вы писали:
А>>чо-то непонял этой возможности для T-SQL нет ? или инстрементария нет ? M>Я могу повторить еще раз, что T-SQL не предназначен для описания бизнес-логики.
Т.е. в хранимых процедурах не бизнес логика? А что?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, aston, Вы писали:
A>>Смотрим начальный пост: M>Это не изначальный..
A>>Полезно, когда возможностей процедурного языка PL/SQL не хватает и надо использовать объектную модель с наследованием и прочей чухней. M>Все дело в том, что объектная модель, сама по себе, выходит за рамки РСУБД. То есть непосредственно от реляционного хранилища данных требовать умения работы с бизнес-логикой несколько не корректно.
A>> Так что Java является полноценным участником БД и рассматривать ее как какую-то примочку, не относящуюся к БД — не нужно. M>Физически да, но логически Ява обеспечивает совсем другой функционал, мало связанный непосредственно с хранением данных.
Да черт с ней, с объектной моделью. Смысл то в том, что у сервера, помимо SQL, есть еще процедурный язык. Так вот — в Oracle их 2 — PL/SQL и Java. В MSSQL это T-SQL. Это языки обработки данных. Причем все они тесно интегрированы с SQL (DML, DDL), т.е. переключение контекста между SQL-engine и PL/SQL(Java, T-SQL)-engine происходит автоматически.
M>И поскольку Оракл предоставляет этот функционал, то он считается не чисто БД, а почти сервером приложений, в отличии от MSSQL, который просто БД без высокоуровневых заморочек.
Значит, если в MSSQL есть T-SQL — он тоже не чисто БД, а почти сервер приложений. Короче говоря, считайте, что Java в Oracle, это как T-SQL в MSSQL.
A>>Интересно, как в Yukon будут писаться SP на шарпе. Надеюсь, так: M>Немного не так, но переключения контекста тоже не происходит. Впрочем раньше времени говорить не буду, пока еще руки не дошли.
Переключение контекста будет происходить обязательно. Просто как это будет выглядеть: автоматически или как, например, при использовании ADO — создаем коннекшен, затем рекордсет, заполняем вручную параметры, выполняем запрос, фетчим записи и т. д.
Здравствуйте, bizhan, Вы писали:
B>Здравствуйте, aston, Вы писали:
B>Это на тему яиц Вы бы их попробовали чтоли B>Что формс-сервер, что репорт-сервер — разницы никакой. И IE ничего там не сделает.
Ну у нас то все отчеты в HTML были.
Ладно, с формсами может погорячился. Щас 6.0 поставил — буду разбираться.
B>>>Здесь речь шла о том, что вот есть у меня разработанные 10 лет назад FMX. B>>>Клиент-сервер и все такое. А заказчик вдруг говорит — хотим тонкого клиента. B>>>А я ему в ответ — завтра. A>>В этом ваша ошибка. Надо было потянуть — бабок поболе затребовать за перевод на тонкого клиента.
B>Вопросы такие: B>1. вы девелопер или менеджер? B>2. это ваш перманентный подход по жизни — "потянуть"? B>3. поболе — это сколько?
B>
Уважаемый — у вас совсем нет чувства юмора.
1). Как говорит Шойгу, когда ему задают вопрос — зачем вы к нам прилетели? Он отвечает — посмотрите название нашего министерства. Так же и я могу ответить — посмотрите на название сайта.
2). Не, ну не "потянуть" — а выдержать паузу. Как правило — весь зуд заказчика проходит через недельку. А вот если неделя прошла — а он еще не забыл, что ему было надо — тогда все серьезно — надо засучивать (или как там это пишется) рукава.
3). Мой Босс (а он в разработке ПО ни бельмеса, как и Главный Босс заказчика) поступил бы именно так. Т.е. он бы спросил меня — сколько это может стоить. Я бы оветил — $500 за 1 раб. место и ни тугрика меньше. Неплохо устроился, а.
Здравствуйте, aston, Вы писали:
A>Да черт с ней, с объектной моделью. Смысл то в том, что у сервера, помимо SQL, есть еще процедурный язык. Так вот — в Oracle их 2 — PL/SQL и Java. В MSSQL это T-SQL.
Да нет же, в MSSQL T-SQL — это именно диалект ANSI SQL и не более того.
A>Короче говоря, считайте, что Java в Oracle, это как T-SQL в MSSQL.
Нет, это не так. T-SQL в принципе предназначен для другого. Ява — это ООП, а SQL — это Relation и наличие/отсутствие переключения контекста здесь никакой роли не играет.
Просто в Оракле сростили две идеологически разные функциональности в одну, поскольку в некоторых случаях это удобно. Но это совершенно не означает того, что их противопоказано использовать по отдельности.
A> автоматически или как, например, при использовании ADO — создаем коннекшен, затем рекордсет, заполняем вручную параметры, выполняем запрос, фетчим записи и т. д.
Практически точно так же как работа с Java в Oracle.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, aston, Вы писали:
A>>Да черт с ней, с объектной моделью. Смысл то в том, что у сервера, помимо SQL, есть еще процедурный язык. Так вот — в Oracle их 2 — PL/SQL и Java. В MSSQL это T-SQL. M>Да нет же, в MSSQL T-SQL — это именно диалект ANSI SQL и не более того.
Давайте оставим стандарты в покое и посмотрим: какую роль имеют процедурные расширения того или иного сервера. Прально — написание процедурного кода, который тесно интегрирован с SQL сервера. И именно в этом контексте что T-SQL, что PL/SQL, что Java выполняют одну и ту же задачу, только Java позволяет писать еще и объектный код.
A>>Короче говоря, считайте, что Java в Oracle, это как T-SQL в MSSQL. M>Нет, это не так. T-SQL в принципе предназначен для другого. Ява — это ООП, а SQL — это Relation и наличие/отсутствие переключения контекста здесь никакой роли не играет.
Ну в чем различие в их предназначении:
T-SQL
GO
CREATE PROCEDURE SomeProc
AS--some t-sql code here
GO
PL/SQL
CREATE OR REPLACE PROCEDURE SomeProc
IS
BEGIN--some pl/sql code hereEND;
Java SP
CREATE OR REPLACE PROCEDURE SomeProc
AS LANGUAGE JAVA
NAME 'SomeClass.SomeProc'
+
public class SomeClass {
public static void SomeProc () {
//some Java code here
}
}
Почему Oracle так поступил? Я думаю, там следут логике, что дешевле и эффективнее обрабатывать данные там, где они хранятся, т.е. на сервере. А клиенту выдавать уже обработанный и подготовленный рзеультат. В этом плане надобность в App-сервере действительно как-то пропадает.
M>Просто в Оракле сростили две идеологически разные функциональности в одну, поскольку в некоторых случаях это удобно. Но это совершенно не означает того, что их противопоказано использовать по отдельности.
Просто Oracle наплевал на стандарты и ушел вперед и это надо признать. MS пока в роли догоняющего и ударными темпами мутит Yukon.
Все это мое IMHO и переубеждать меня в этом безполезно.
Здравствуйте, TK, Вы писали:
TK>Hello, "aston"
>> Переключение контекста будет происходить обязательно.
TK>Вопрос. Какой смысл вкладывается в слова "Переключение контекста" (в контексте данного обсуждения конечно)?
Вопрос обширный (надо цитировать матчасть), но если в 2-х словах, то это использование одного языка в другом без дополнительных телодвижений.
В PL/SQL это так:
DECLARE--это PL/SQL
SomeVar NUMBER; --это PL/SQLBEGIN--это PL/SQLSELECT--а это уже SQL - switch context и парсим это выражение как SQL
SomeField --SQLINTO--SQL
SomeVar --SQLFROM--SQL
SomeTable; --SQLIF SomeVar > 0 THEN--а это снова PL/SQL - switch context и снова парсим как PL/SQLNULL; --это PL/SQLEND IF; --это PL/SQLEND; --это PL/SQL
В гипотетическом C/SQL это могло бы выглядеть так:
{
int SomeVar; //это С
SELECT //а это уже SQL - switch context и парсим это выражение как SQL
SomeField //SQL
INTO //SQL
SomeVar //SQL
FROM //SQL
SomeTable; //SQLif (SomeVar > 0) {}; // а это снова C - switch context и снова парсим как С
}
Извиняюсь за кривоту с комментами. Я ставлю Tab, а в превью идет замена на пробелы.
Здравствуйте, aston, Вы писали:
A>Давайте оставим стандарты в покое и посмотрим: какую роль имеют процедурные расширения того или иного сервера.
Ладно, давайте смотреть более абстрактно, в конце-концов брать какой-то конкретный язык это не совсем верно. Что ребуется от абстрактного реляционного хранилища данных? Уметь положить в реляционное хранилище, уметь взять из него и преобразовать в другой вид (попрежнему реляционный), посредством операторов реляционной алгебры. Все, требовать от хранилища чего-то большего смысла не имеет.
И в данном случае процедурное расширение — это метод работы с данными посредством операторов реляционной алгебры и ничего больше. Всем остальным, по идеологии MS занимается клиентский код и в этом смысле MS от чистого хранилища практически не отходил.
A>Ну в чем различие в их предназначении:
В том, что T-SQL работает только с реляционными данными и по другому не умеет, да и не должен.
Ява же работает с объектами, и для преобразования реляционных данных в объекты нужен хотя бы минимальный ORM. При этом непосредственно к данным обращается все равно SQL.
Ровно с тем же успехом все Яву можно использовать на клиенте, а вот SQL от сервера оторвать уже не полчится.
A>Почему Oracle так поступил? Я думаю, там следут логике, что дешевле и эффективнее обрабатывать данные там, где они хранятся, т.е. на сервере. А клиенту выдавать уже обработанный и подготовленный рзеультат.
А вот это уже очень и очень спорное утверждение. По крайней мере это верно далеко не всегда.
A>Просто Oracle наплевал на стандарты и ушел вперед и это надо признать. MS пока в роли догоняющего и ударными темпами мутит Yukon.
Как уже совершенно верно заметил TK, добавление Net в сервер, по большому счету, лишь дань моде и больше чем на сервис-пак не тянет, так же как и добавление версионности. При желании они могли бы сделать это гораздо раньше. К примеру, по непроверенным данным, добавление версионности обошлось просто-таки в смешное количество человеко-часов. Ну это так, к слову.
Вы правы в одном, MS действительно приходится догонять Оракл, но несколько в другом смысле, чем Вы думаете. Мне тут подкинули довольно интересную мысль и думаю, что в ней есть зерно истины.
Дело в том, что сейчас все прогрессивное человечество, в едином порыве, переползает на 64 разрядный Intel, и подобный переход довольно серьезно влияет на относительно высокоуровневые алгоритмы. У Oracle есть нехилый опыт написания под под подобную архитектуру на спарках, чего не скажешь про MS и даже, как говорят, про команду разработчиков DB2 UDB (хотя по идее уж IBM'ерам-то опыта не занимать).
Кстати, думаю, что по большей части именно в этом и кроется причина успеха 10g в tpc-c тестах, на фоне провального выступления девятки. Там уже давно 64 процессорные машины, и, судя по всему вовремя почуяв момент, Оракл воспользовался своим опытном и весьма удачно реализовал спарковские наработки.
A>Все это мое IMHO и переубеждать меня в этом безполезно.
Да я и не собираюсь..
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[16]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
11.01.04 18:14
Оценка:
с огромным интересом прочитал ваш ответ. много думал ...
но поскольку думал во сновном о всяких пошлостях все же решил перечитать ваш пост и знаете, понял что пост этот чо-то не несет информации
Java не часть БД. Не физически (физически я могу БД заставить хоть кофе варить), а логически, она выполняет совершенно другие функции, отличные от тех для которых предназначена БД.
БД — это хранилище данных и хранением занимается SQL, а Java занимается обработкой и то, что Java физически находится примерно там же и может вызывать SQL команды напрямую, никакой роли не играет.
можно все таки хоть несколько аргументов, с учетом SQLJ http://www.osp.ru/os/1999/09-10/061.htm
допустим sql
select count(*) from table
коренным образом отличается от
select myjavafunction(*) from table
т.к. ...
Здравствуйте, <Аноним>, Вы писали:
А>с огромным интересом прочитал ваш ответ. много думал ...
Видимо не помогло..
А>можно все таки хоть несколько аргументов
Я все еще жду определения RDBMS.
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[11]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
11.01.04 19:52
Оценка:
Здравствуйте, Alexey_ch, Вы писали:
A_>Здравствуйте, Merle, Вы писали:
А>>>чо-то непонял этой возможности для T-SQL нет ? или инстрементария нет ? M>>Я могу повторить еще раз, что T-SQL не предназначен для описания бизнес-логики.
A_>Т.е. в хранимых процедурах не бизнес логика? А что?
Physical two-tier implementation with a fat server
In a physical two-tier implementation with a fat server, business logic and presentation services are deployed from the server database. In this implementation, business logic is generally written as stored procedures and triggers within the database. For example, in the TPC-C benchmarks published for Microsoft SQL Server, the core transaction logic is coded as Transact–SQL stored procedures in the server. Many internally-developed corporate applications also make extensive use of stored procedure logic. Microsoft uses this implementation to handle internal business functions, such as customer information tracking.
ну зачем заострять внимание, кому это интересно в этой ветке уже давно все поняли
Gt_
Re[18]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
11.01.04 20:30
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>с огромным интересом прочитал ваш ответ. много думал ... M>Видимо не помогло..
А>>можно все таки хоть несколько аргументов M>Я все еще жду определения RDBMS.
только у меня просьба — подверждайте ссылками хотябы на МС
Relational Database Components
The database component of Microsoft® SQL Server™ 2000 is a Structured Query Language (SQL)–based, scalable, relational database with integrated Extensible Markup Language (XML) support for Internet applications. Each of the following terms describes a fundamental part of the architecture of the SQL Server 2000 database component:
Database
A database is similar to a data file in that it is a storage place for data. Like a data file, a database does not present information directly to a user; the user runs an application that accesses data from the database and presents it to the user in an understandable format.
Database systems are more powerful than data files in that data is more highly organized. In a well-designed database, there are no duplicate pieces of data that the user or application must update at the same time. Related pieces of data are grouped together in a single structure or record, and relationships can be defined between these structures and records.
When working with data files, an application must be coded to work with the specific structure of each data file. In contrast, a database contains a catalog that applications use to determine how data is organized. Generic database applications can use the catalog to present users with data from different databases dynamically, without being tied to a specific data format.
A database typically has two main parts: first, the files holding the physical database and second, the database management system (DBMS) software that applications use to access data. The DBMS is responsible for enforcing the database structure, including:
Maintaining relationships between data in the database.
Ensuring that data is stored correctly, and that the rules defining data relationships are not violated.
Recovering all data to a point of known consistency in case of system failures.
Relational Database
Although there are different ways to organize data in a database, relational databases are one of the most effective. Relational database systems are an application of mathematical set theory to the problem of effectively organizing data. In a relational database, data is collected into tables (called relations in relational theory).
A table represents some class of objects that are important to an organization. For example, a company may have a database with a table for employees, another table for customers, and another for stores. Each table is built of columns and rows (called attributes and tuples in relational theory). Each column represents some attribute of the object represented by the table. For example, an Employee table would typically have columns for attributes such as first name, last name, employee ID, department, pay grade, and job title. Each row represents an instance of the object represented by the table. For example, one row in the Employee table represents the employee who has employee ID 12345.
When organizing data into tables, you can usually find many different ways to define tables. Relational database theory defines a process called normalization, which ensures that the set of tables you define will organize your data effectively.
Structured Query Language
To work with data in a database, you have to use a set of commands and statements (language) defined by the DBMS software. Several different languages can be used with relational databases; the most common is SQL. The American National Standards Institute (ANSI) and the International Standards Organization (ISO) define software standards, including standards for the SQL language. SQL Server 2000 supports the Entry Level of SQL-92, the SQL standard published by ANSI and ISO in 1992. The dialect of SQL supported by Microsoft SQL Server is called Transact-SQL (T-SQL). T-SQL is the primary language used by Microsoft SQL Server applications.
Extensible Markup Language
XML is the emerging Internet standard for data. XML is a set of tags that can be used to define the structure of a hypertext document. XML documents can be easily processed by the Hypertext Markup Language, which is the most important language for displaying Web pages.
Although most SQL statements return their results in a relational, or tabular, result set, the SQL Server 2000 database component supports a FOR XML clause that returns results as an XML document. SQL Server 2000 also supports XPath queries from Internet and intranet applications. XML documents can be added to SQL Server databases, and the OPENXML clause can be used to expose data from an XML document as a relational result set.
Здравствуйте, <Аноним>, Вы писали:
А>только у меня просьба — подверждайте ссылками хотябы на МС
Я не просил описания что такое MSSQL, я просил определение RDBMS и, в частности, что в Вашем понимании означает термин Relation.
Здравствуйте, <Аноним>, Вы писали:
А>ну зачем заострять внимание, кому это интересно в этой ветке уже давно все поняли
Вот уж действительно, сложно не согласиться.
... [RSDN@Home 1.1.0 stable]
Мы уже победили, просто это еще не так заметно...
Re[20]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
11.01.04 21:36
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>только у меня просьба — подверждайте ссылками хотябы на МС M>Я не просил описания что такое MSSQL, я просил определение RDBMS и, в частности, что в Вашем понимании означает термин Relation.
ну ... вы меня разочаровываете, зачем нам демагогия или мое понимае или чем то источник msdn не подходит ? так мы его запросто сменим на оракловый мы сравниваем 2 конкретные СУБД, я человек наивный — безрасудно верю M$ и Oracle ... вот МС огласило, что по их мнению входит в Relational Database Components, они врут ?
нет ? тогда может тут кто-то (не будем говорит кто хотя это был кролик (С) Винни Пух) тут чо-то нетого ?
итак давайте соберемся и ответим гнусным анонимусам не трогая бедалагу Кодда !
Здравствуйте, Sinclair, Вы писали:
S>Ну, зерно поинта суть в том, что все-таки T-SQL ежели честно позиционируется как язык для написания BL. Увы, в настоящее время ограничиться только хранением состояния (например реляционной алгеброй) могут себе позволить только академические СУБД.
Ну позиционировать-то они его могут как угодно, но реально за рамки реляционной алгебры T-SQL далеко не выполз, да и не смог бы. Естественно низкоуровневая часть БЛ реализуется на уровне SQL'я, но основная часть все равно ложится на клиента.
А вот введение ОО языка в БД для обработки данных — это уже качественный выход из рамок чистой БД.
S>Отлично, ребята, если ваше приложение на Delphi начинает неприлично распухать — нет проблем, ставтье Middle-tier и все в порядке. "Но я ведь всего лишь хотел сделать так, чтобы при вставке итема в ордер пересчитывалась сумма ордера...". Те производители СУБД, которые встроили поддержку триггеров, резко вырвались вперед — с точки зрения движка, это почти ничего не стоит.
Ну вот здесь-то по большому счету триггеры и не нужны. Да и сами по себе триггеры не выходят за границы "просто БД", все-таки работа идет с реляционными данными, и тут все "по честному".
S>В настоящее время мы имеем ту же ситуацию. Некоторые производители СУБД встраивают поддержку языков общего назначения, чтобы стать "ближе к народу".
Вообщем-то да, но это качественно другой уровень. А в целом согласен.
Здравствуйте, <Аноним>, Вы писали:
А>ну ... вы меня разочаровываете, зачем нам демагогия или мое понимае
А зачем мы тогда вообще здесь время теряем?
А>нет ? тогда может тут кто-то (не будем говорит кто хотя это был кролик (С) Винни Пух) тут чо-то нетого ?
Тем более, зачем мы здесь теряем время на Ваш искрометный юмор?
А>итак давайте соберемся и ответим гнусным анонимусам не трогая бедалагу Кодда !
Оные анонимусы, откровенно говоря, порядком надоели. Упражняться во взаимном ехидстве я предпочитаю в других местах, а поделу они либо не понимают, лбо делают вид, что не понимают, несколько неуклюже меняя тему разговора и не отвечая по существу. Ко всему прочему, не приведя ни одной цитаты по делу и не употребив практически ни одного термина по назначению.
Посему разговор пора завязывать, благо все всё давно уже поняли.
Здравствуйте, Merle, Вы писали: M>Ну позиционировать-то они его могут как угодно, но реально за рамки реляционной алгебры T-SQL далеко не выполз, да и не смог бы.
Merle мне друг, но истина дороже Операторы ветвления, циклы, введение переменных и операции с курсорами — это все процедурное программирование (as opposed to декларативный SQL). Равно как и ХП и оператор execute. Увы и ах. M>А вот введение ОО языка в БД для обработки данных — это уже качественный выход из рамок чистой БД.
Неа. Это качественный выход из рамок процедурного сервера приложений M>Ну вот здесь-то по большому счету триггеры и не нужны. Да и сами по себе триггеры не выходят за границы "просто БД", все-таки работа идет с реляционными данными, и тут все "по честному".
Неа. Путем триггеров наша СУБД имеет наглость обладать поведением. Вместо того, чтобы чисто хранить то, что в нее положили. Упс. M>Вообщем-то да, но это качественно другой уровень.
Можно и так сказать. Хотя я как-то больше склоняюсь к тому, что это скорее количественное изменение. Уж очень там ОО ограничено.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Merle, Вы писали:
M>Я все еще жду определения RDBMS.
Кстати, это еще в будущем, о чем я сейчас собираюсь сказать, для нас разработчиков. Но у нас будет неплохой шанс очень приятно и свободно использовать Оракл как Объектную БД. На сегодняшний день уже восьмерка стала Объектно-Реляционной БД. И появление Java далеко не случайность. Уже есть смысл спрашивать определение ORDBMS.
Здравствуйте, theOne, Вы писали:
O> Но у нас будет неплохой шанс очень приятно и свободно использовать Оракл как Объектную БД. На сегодняшний день уже восьмерка стала Объектно-Реляционной БД.
Не думаю, по крайней мере не в ближайшее время. Есть вполне объективные причины того, что не смотря на победное шествие ОО по всей планете, реляционные БД не собираются сдавать свои позиции.
O>И появление Java далеко не случайность. Уже есть смысл спрашивать определение ORDBMS.
Для начала надо определиться с тем, что такое ОО, а потом уже приплести к этому DBMS и, возможно, R. На сколько мне известно даже четкого определения, что такое ОО, по сути не существует, все интуитивно понимают, что это такое, но сформулировать никто не может.
Здравствуйте, Sinclair, Вы писали:
S>Merle мне друг, но истина дороже
S>Операторы ветвления, циклы, введение переменных и операции с курсорами — это все процедурное программирование (as opposed to декларативный SQL). Равно как и ХП и оператор execute. Увы и ах.
Ок, сойдемся на том, что истина посередине. Признаю, что немного увлекся теоретизированием, глупо было бы отрицать, что T-SQL не чисто декларативный язык. Но опять-таки далеко оттуда он не уполз.
S>Неа. Это качественный выход из рамок процедурного сервера приложений
Хм... Чур меня. Это выход из рамок БД, умеющей интеллектуально распихивать данные по табличкам (можно конечно назвать это процедурным app-сервером, но я бы не стал ). Причем именно данные, а не объекты. Для такой БД из объектов данные делает тот дядька..
S>Неа. Путем триггеров наша СУБД имеет наглость обладать поведением. Вместо того, чтобы чисто хранить то, что в нее положили. Упс.
Ну я ж говорю, интеллектуальное хранение того, что в нее положили. Из рамок реляционного хранилища это не вылезает.
Вообще все эти границы очень и очень размыты. Никогда нельзя сказать на сто процентов: "вот здесь у меня data layer, здесь business, а здесь presentation". Но более-менее акценты расставить можно.
В app-БД business уровень смещен в сторону хранилища, в "чистой" же БД, как правило, необходимо наличие ярковыраженного среднего слоя.
Здравствуйте, Merle, Вы писали:
M>Для начала надо определиться с тем, что такое ОО, а потом уже приплести к этому DBMS и, возможно, R. На сколько мне известно даже четкого определения, что такое ОО, по сути не существует, все интуитивно понимают, что это такое, но сформулировать никто не может.
Ну формулировок хоть отбавляй и конкретных реализаций. Просто базируется все понятие ОО на высокоуровневых понятиях. Как в С++ нет понятия статических виртуальных методов, но это не значит, что такого нет вообще.
С другой стороны ОО для БД особенно в подходе хранения данных и развивается независимо от стандартов. Когда на стороне сервера можно будет применять весь арсенал компилируемых ООяП, тогда они наверное и будут в полной мере соответствовать ООБД.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, <Аноним>, Вы писали:
А>версионник на OLTP занимает первые места, позволяет не ограничивать длину транзакции,
Ерунда это все. Длинные транзакции опасны в любой транзакционной системе. Long running transactions это совершенно отдельная головная боль, универсальным способом нормально не решаемая.
Здравствуйте, aston, Вы писали:
A>Вопрос обширный (надо цитировать матчасть), но если в 2-х словах, то это использование одного языка в другом без дополнительных телодвижений.
Проблема только в том что SQLJ это не хитрые переключения контекста, а банальный препроцессор для джавы.
Здравствуйте, Serginio1, Вы писали:
S> Ну формулировок хоть отбавляй и конкретных реализаций.
Приведи хоть одну..
На самом деле — есть, де факто, минимальный набор требований, которым должна удовлетворять система, чтобы иметь право называться объектной: наследование, инкапсуляция и полиморфизм. Обычно под ОО системой принято понимать именно систему объекты которой обладают этими свойствами.
Это я сейчас Sinclair'а вольно цитирую, если что он поправит..
Но как только объекты в таком виде необходимо сохранить, тут же вылезает ряд проблем связанных с эффективностью их обратного доставания. И здесь OODB проигрывают просто фатально. Причем на столько, что даже те конструкции, которые принято сейчас называть ООБД (хотя по большому счету это не так) этим трем требованиям удовлетворяют лишь отчасти, и все равно, этой части хватает чтобы сливать RDBMS со страшной силой, на более-менее широком классе задач.
S> С другой стороны ОО для БД особенно в подходе хранения данных и развивается независимо от стандартов.
Но пока как-то очень робко, и не невнятно. Каких либо определенных успехов в это направлении не наблюдается уже много лет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ерунда это все. Длинные транзакции опасны в любой транзакционной системе. Long running transactions это совершенно отдельная головная боль, универсальным способом нормально не решаемая.
Андрей, лучше не ввязывайся, с пониманием там бедулька...
Здравствуйте, Merle, Вы писали:
S>> С другой стороны ОО для БД особенно в подходе хранения данных и развивается независимо от стандартов. M>Но пока как-то очень робко, и не невнятно. Каких либо определенных успехов в это направлении не наблюдается уже много лет.
По поводу структур хранения данных я уже много раз проходился, и надстройка ООП над РБД легко строится особенно на локальных базах, но ввод Явы а тем более его синтеза с SQL на стороне сервера только радует и надеюсь, что данный поход будет развиваться и в Юконе.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
12.01.04 21:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, <Аноним>, Вы писали:
А>>версионник на OLTP занимает первые места, позволяет не ограничивать длину транзакции,
AVK>Ерунда это все. Длинные транзакции опасны в любой транзакционной системе. Long running transactions это совершенно отдельная головная боль, универсальным способом нормально не решаемая.
ерунда все это конечно весомый оргумет, но хотелось бы деталей ... например для реализации оракла. т.е. при каких условиях, какой выйгрышь и т.п.
от Мерле кроме авторитетного заявления "Особенно учитывая каким образом Оракл мудрит с RW транзакциями при RC, а при snapshot'е все еще грустнее — там версионник сливает по определению." выудить ничего не удалось
мой аргумент см чуть выше.
Здравствуйте, Sinclair, Вы писали:
S>Есть у меня подозрение, что они таки сделали блокировки со всеми теми эскалациями, которыми пугают юных оракл-девелоперов .
Ну это-то вряд-ли , скорее причина в другом.
В чем именно станет известно после того, как появится документация на 10G. Но в целом, похоже, причина кроется в том, что в tpc-c тесте уже используются 64 процессорные машины, которые у интела появились относительно недавно. А это довольно серьезное изменение в архитектуре, которое, если брать БД, отражается на сканировании индексов, и прочей низкоуровневой рутине которой занимается ядро. У Oracle есть большой опыт работы с подобными системами на спарках и уже готовые решения, чего про MS не скажешь.
Опять-таки можно выудить немного полезной информации если посмотреть на tpc-c по внимательнее.
Обрати внимание на 5 и 6 позицию. Oracle и DB2 на практически идентичных машинах и одной и той же ОС, показывают практически одинаковый результат. Но если копнуть поглубже, то выясняется, что разница в железе все же есть. И та и та система в качестве хранилища использовала около 2000 винтов, но если DB2 понадобилось 26 фибероптических контроллеров, то Oracle, чтобы достичь той же производительности, понадобилось 66.
Из этого можно сделать вывод, что с, хорошей вероятностью, система ввода/вывода у Oracle все-таки работает не без проблем...
Мы уже победили, просто это еще не так заметно...
Re[9]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
13.01.04 11:01
Оценка:
S>Просто Merle прямо в этом форуме уже дважды читал курсы лекций по особенностям поведения Oracle при выполнении RW транзакций. Вряд ли ему захочется делать это же в третий раз. По крайней мере до выхода нового оракла. А Андрей совершенно прав. Люители длинных RW транзакций положат как версионник, так и блокировочник. Если интересно почему — рекомендую все-таки пойти в книжный магазин. Трудно в форуме изложить 200 страниц теории. Вкратце и так все очевидно — deadlock это deadlock, независимо от стратегии изоляции. Поддержка изоляции съедает ресурсы, и чем длиннее транзакция, тем больше этих ресурсов. По поводу OLTP — версионники сливают. До выхода 10g говорить о выступлениях Oracle в OLTP было вообще смешно. Сейчас на tpc запощены результаты, которые позволяют Oracle надеяться на лучшее. Тем не менее, статус их до сих пор in review, а сопоставимая с МССКЛ цена транзакции в минуту достигается только в одном из варинатов. Я плохо знаю Оракл, поэтому не в курсе, какие такие изменения по сравнению с 9кой позволили им так вырваться вперед. Есть у меня подозрение, что они таки сделали блокировки со всеми теми эскалациями, которыми пугают юных оракл-девелоперов .
совсем не обязательно тут пересказывать ... достаточно одной ссылки, с указанием где зерно ... только умоляю — не на Мерле. я извиняюсь но он порет откровеную чушь (например топик про блокировки II).
из ваших строк я понял 2 проблемы — дедлог и ресурсы? так ?
1. из-за того что кол-во блокировок в оракле на порядок меньше — напоротся на дедлог в хорошо продуманой системе ну ооочень тяжело, но ок — наверно возможно, однако это точно не сможет быть причиной для серьезного падения производительности — если нужно просто опять кусок статьи Kyte запощу.
2. Ресурсы — какие ресурсы ? роллбэк сегменты, память ? можно огласить список ресурсуров которых израсходуется больше ?
в OLTP у блокировочника есть преимущество, но в реальной жизни очень редко встречается такая идеальная как в тестах задача и тут рульность версионности вылазит во всей красе. МС это видит и с хорошими темпами догоняет оракл по многим статьям. версионная модель Юкона вытеснит блокировочную, также как это роизошло в опен сорсе — posgres, firebird, mysql — я не знаю ни одной бд в опен сорсе блокировочника.
на данный момент как в прочем и много лет до этого оракл всех делает больше чем на 20% на любых тестах, поэтому я всетаки предлагаю хватит смешных аргументов типа "версионники сливают", оракл как был 30 лет назад первым (первая РСУБД) так и сейчас. девятку они поставили RACом и запихнули всякую ерунду, поэтому и было там пару процентов отстование, но это все реализация конкретной версии. посиотрите что было 5-10 лет назад. выйдет Юкон померием обе модели ок ?
ладно чо-то мы серьезные сегодня .. нада передать привет хорошему модератору Мерле
Здравствуйте, theOne, Вы писали:
O>Не вижу какая трудность по сохранению объектов и извлечению таковых?
Нууу.. В твоем примере нет
1. Наследования
2. Инкапсуляции
3. Полиморфизма
То есть, с точки зрения ООП, здесь и не объекты вовсе, а структуры. Я уже не говорю о виртуальных методах и прочих тонких материях.
Чтобы понять в чем здесь глобальная засада, возьмем например инкапсуляцию. Допустим в объекте есть метод, который возвращает какое-то значение по очень хитрому алгоритму. Построить сколь-либо эффективный индекс, по этому методу нельзя, так как нет доступа ни к реализации этого метода, ни к приватным полям, на основе которых метод и делает свои расчеты. Таким образом поиск объекта по значению этого метода выливается даже не просто в table scan, а в то, что каждый объект надо поднять из хранилища в память, вызвать метод, подождать пока он там что-то посчитает, проверить результат и положить обратно, если результат не удовлетворительный. В итоге перфоманс просто убойный.
Ясное дело, что это в принципе поддается некоторой оптимизации, но пока серьезных успехов на этом фронте не достигнуто.
O>Такое ощущение, что вы ответы на ходу иногда пытаетесь придумать.
Не доверяй им (ощущениям)..
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, theOne, Вы писали:
O>>Не вижу какая трудность по сохранению объектов и извлечению таковых? M>Нууу.. В твоем примере нет M>1. Наследования M>2. Инкапсуляции M>3. Полиморфизма M>То есть, с точки зрения ООП, здесь и не объекты вовсе, а структуры. Я уже не говорю о виртуальных методах и прочих тонких материях.
M>Чтобы понять в чем здесь глобальная засада, возьмем например инкапсуляцию. Допустим в объекте есть метод, который возвращает какое-то значение по очень хитрому алгоритму. Построить сколь-либо эффективный индекс, по этому методу нельзя, так как нет доступа ни к реализации этого метода, ни к приватным полям, на основе которых метод и делает свои расчеты. Таким образом поиск объекта по значению этого метода выливается даже не просто в table scan, а в то, что каждый объект надо поднять из хранилища в память, вызвать метод, подождать пока он там что-то посчитает, проверить результат и положить обратно, если результат не удовлетворительный. В итоге перфоманс просто убойный. M>Ясное дело, что это в принципе поддается некоторой оптимизации, но пока серьезных успехов на этом фронте не достигнуто.
O>>Такое ощущение, что вы ответы на ходу иногда пытаетесь придумать. M>Не доверяй им (ощущениям)..
Не соглашусь. Объект может опираться на несколько записей которые считываются по мере необходимости. А так как объект. Записи очень удобно хранить в обычных таблицах а доступ к полям через свойства с применением Inline, а в качестве первичного ключа Хэш таблицу. Для того что бы не считывать запись можно вычислять адрес этой записи в памяти если она загружена итд. И уверяю скороость очень высокая. Во всяком случае у меня на ФоксПро с ее дубовым форматом.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Объект может опираться на несколько записей которые считываются по мере необходимости.
Так это как раз то, что есть сейчас.
Объект в ручную, распихивается по реляционным табличкам.
S>Записи очень удобно хранить в обычных таблицах а доступ к полям через свойства с применением Inline,
Что есть в данном случае inline?
S> а в качестве первичного ключа Хэш таблицу.
Какие данные хешировать?
S>Для того что бы не считывать запись можно вычислять адрес этой записи в памяти если она загружена итд.
В данном случае у записи нет значения как такового. Оно вычисляемое, причем алгоритм не известен. Пока метод явно не вызовешь значение записи узнать не возможно.
S>И уверяю скороость очень высокая. Во всяком случае у меня на ФоксПро с ее дубовым форматом.
Так у тебя там опять же структуры лежат, а не ОО объекты, раз ты к любым полям доступ имеешь.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Объект может опираться на несколько записей которые считываются по мере необходимости. M>Так это как раз то, что есть сейчас. M>Объект в ручную, распихивается по реляционным табличкам.
На самом деле это даже саме то, т.к. хранить объект в сериализованном виде неоптимально, да и с точки зрения хранения данных и модификации S>>Записи очень удобно хранить в обычных таблицах а доступ к полям через свойства с применением Inline, M>Что есть в данном случае inline?
В С есть понятие инлайн, когда всесто вызова процедуры подставляется ее код, тем самым сокращая время вызова метода.
S>> а в качестве первичного ключа Хэш таблицу. M>Какие данные хешировать?
Первичный ключ, обычно используются Б+ деревья для связи. S>>Для того что бы не считывать запись можно вычислять адрес этой записи в памяти если она загружена итд. M>В данном случае у записи нет значения как такового. Оно вычисляемое, причем алгоритм не известен. Пока метод явно не вызовешь значение записи узнать не возможно.
Не совсем так, все зависит от алгоритма, на первом то этапе можно выбрать оптимальный метод выборки, а уж доступ к полям уже происходит через свойства, которые загружают новые данные объекта если поле является ссылкой.
S>>И уверяю скороость очень высокая. Во всяком случае у меня на ФоксПро с ее дубовым форматом. M>Так у тебя там опять же структуры лежат, а не ОО объекты, раз ты к любым полям доступ имеешь.
Я выше объяснял, что объекты хранить не нужно, только его данные, это несколько другой подход, но все же ОО.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> На самом деле это даже саме то, т.к. хранить объект в сериализованном виде неоптимально, да и с точки зрения хранения данных и модификации
С точки зрения хранения как раз очень оптимально...
M>>Что есть в данном случае inline? S> В С есть понятие инлайн, когда всесто вызова процедуры подставляется ее код, тем самым сокращая время вызова метода.
Да что это такое inline в С — я знаю, что есть инлайн в данном случае? Я так понимаю, ты хочешь подставлять уже посчитанное значение, но так не всегда можно сделать.
S> Первичный ключ, обычно используются Б+ деревья для связи. Ну только мне-то рассказывать не надо...
Если у тебя уже есть посчитанное значение метода, то не вопрос, но оно есть не всегда и тогда хэш таблицу делать не на чем.
Черт, ты всегда берешь конкретную реализацию, попробуй представить ситуацию более абстрактно — нет никакой ложки(хешь таблиц)
Давай считать так, если у нас константа, значит мы можем построить какой угодно индекс и добраться по бырому, но несли нет, то фиг ты чего построишь.
S>>>Для того что бы не считывать запись можно вычислять адрес этой записи в памяти если она загружена итд.
Это уже оптимизация о которой сейчас говорить рано, мы пока рассматриваем чистую модель.
S> Не совсем так, все зависит от алгоритма,
Фокус в том, что ты не знаешь алгоритм.. Ясен хобот, что когда алгоритм известен можно просто с бешенной силой все прооптимизировать. Но в общем случае алгоритм не известен, он скрыт внутри объекта и кроме объекта о нем никто не знает. Его там может вообще не быть, это может быть константа, но об этом никто, кроме самого объекта даже не догадывается.
S> Я выше объяснял, что объекты хранить не нужно, только его данные, это несколько другой подход, но все же ОО.
Если понимать под данными приватные поля, то это уже не ОО. А если результаты вызовов методов, то нет гарантии, что они актуальны.
Здравствуйте, Merle, Вы писали:
M>Ну это-то вряд-ли , скорее причина в другом. M>В чем именно станет известно после того, как появится документация на 10G. Но в целом, похоже, причина кроется в том, что в tpc-c тесте уже используются 64 процессорные машины,
Думаю не станет, у меня складывается ощущение, что проблема у Oracle 8-9 была в элементарном баге,
который они внесли в 8.0 и умудрились не замечать до выхода 10-ки, так что в этом они врят ли признаются.
Суть в том, что ошибка ORA-8177 (cannot serialize access for this transaction) в этих версиях возникает
не только когда положено, но и в некоторых других случаях (even though there is no DML on the tables
being queried.) (Bug 2728408 на металинке).
Т.е. откат и перезапуск транзакций по ORA-8177 при выполнении теста tpc-c вероятно происходил чаще чем нужно.
Это конечно догадки, но никаких изменений в механизме Concurency Control Oracle не объявлял, да и на 64-разрядной плотформе и восьмерка и девятка умели крутится, не думаю что в этом сумели сделать какой то прорыв.
Bug 2728408 False ORA-8177 possible SELECTING data with SERIALIZABLE
This note gives a brief overview of bug 2728408.
Affects:
Product (Component) Oracle Server (RDBMS)
Range of versions believed to be affected Versions >= 8.0 but < 10G
Versions confirmed as being affected 8.1.7.4 9.2.0.3
Platforms affected Generic (all / most platforms affected)
Fixed:
This issue is fixed in 9.2.0.4 (Server Patch Set) 10G Production Base Release
Symptoms:
* Error may occur <javascript:taghelp('TAGS_ERROR')>
* ORA-8177
Related To:
* (None Specified)
Description Concurrent selects may get ORA-8177 (cannot serialize access
for this transaction) even though there is no DML on the tables
being queried.
Здравствуйте, KisA, Вы писали:
KA>Думаю не станет, у меня складывается ощущение, что проблема у Oracle 8-9 была в элементарном баге, который они внесли в 8.0 и умудрились не замечать до выхода 10-ки, так что в этом они врят ли признаются.
Не, баг действительно не самый крупный, к тому же там и другие есть, которые, правда, наоборот улучшают результаты тестов..
Я думаю, что они довольно давно о нем знали, и в тестах вполне удачно обходили, но исправление подобных вещей — это серьезное копание внутри ядра и в лет тут не поправишь.
KA>Суть в том, что ошибка ORA-8177 (cannot serialize access for this transaction) в этих версиях возникает не только когда положено, но и в некоторых других случаях (even though there is no DML on the tables being queried.)
Да, я знаю. О нем еще Sergey Ten писал некоторое время назад.
Видимо это следствие того, что версионность в Оракле на уровне страниц данных, и информация о версиях конкретных записей может быть утеряна. В этом случае, чтобы избежать некорректного поведения, Оракл решает перебдеть и откатывает транзакцию.
KA>Это конечно догадки, но никаких изменений в механизме Concurency Control Oracle не объявлял
Ну там действительно, скорее всего только баги поправили. Но про изменения в storage engine они все-таки писали, и думаю, что не с проста.
KA> да и на 64-разрядной плотформе и восьмерка и девятка умели крутится, не думаю что в этом сумели сделать какой то прорыв.
Умели, но не очень шустро, опять же и MSSQL2000, вполне на 64-разрядной машине крутился.
Но у MS еще проблема в том, что им и ОС надо под 64-разряда переписывать. А в распоряжении Оракла есть опыт написания аналогичных систем под спарки и проверенные 64-разрядные юниксы.
Так что прорыва никакого действительно не сделали, а просто удачно применили свой опыт в разработке софта под такие системы.
Мы уже победили, просто это еще не так заметно...
Re[11]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
13.01.04 14:38
Оценка:
я сдаюсь ! да Мерле вы меня убедили — ваши доводы информативны и бесспорны (Как хорошо показывает практика), а аргументы убедительны (нет ответа — топик переносится) и подверждены ссылками на тесты и компетентные источники. мне нечем крыть (матом не дают, посты исчезают)
вы открыли мне глаза — блогодоря вашему опыту я узнал, что T-SQL не предназначен для бизнес-логики, джава не чать бд, DMO — это аналог Оракловской Явы и даже круче, а сервер малых рабочих групп оракл нервно курит когда на сцену выходит сиквел ...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> На самом деле это даже саме то, т.к. хранить объект в сериализованном виде неоптимально, да и с точки зрения хранения данных и модификации M>С точки зрения хранения как раз очень оптимально...
M>>>Что есть в данном случае inline? S>> В С есть понятие инлайн, когда всесто вызова процедуры подставляется ее код, тем самым сокращая время вызова метода. M>Да что это такое inline в С — я знаю, что есть инлайн в данном случае? Я так понимаю, ты хочешь подставлять уже посчитанное значение, но так не всегда можно сделать.
Давай разбирать типичный SQL проход по записям с выставлением блокировок или сравнением версий. Для этого нужен один объект для навигации для объектов наследуемых от одного базового класса. Он же будет выбирать индекс выборки , считывать данные, в объект и накладывать блокировки если нужно или возложить эту обязанность на сам объект. Внутри этих объектов будет творится очень много действий, но выглядеть это будет как обычный объект M>Давай считать так, если у нас константа, значит мы можем построить какой угодно индекс и добраться по бырому, но несли нет, то фиг ты чего построишь.
Опять же. Сначало нужно плясать от форматов хранения данных. Константа может представлять собой некую запись в таблице или Блоб данные. Можно абстракто описать модель, но она должна базироваться уже на какойто модели хранения данных
S>> Не совсем так, все зависит от алгоритма, M>Фокус в том, что ты не знаешь алгоритм.. Ясен хобот, что когда алгоритм известен можно просто с бешенной силой все прооптимизировать. Но в общем случае алгоритм не известен, он скрыт внутри объекта и кроме объекта о нем никто не знает. Его там может вообще не быть, это может быть константа, но об этом никто, кроме самого объекта даже не догадывается.
Тогда это плохо продуманный объект. Всегда можно и нужно на этапе разработки продумать все возможные алгоритмы выборки (не так их уж и много) но уже дальше плясать только от них. S>> Я выше объяснял, что объекты хранить не нужно, только его данные, это несколько другой подход, но все же ОО. M>Если понимать под данными приватные поля, то это уже не ОО. А если результаты вызовов методов, то нет гарантии, что они актуальны.
Выше объснял, что доступ осуществляется через свойства, которые должны гарантировать актуальность результатов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Давай разбирать типичный SQL проход по записям с выставлением блокировок или сравнением версий. Для этого нужен один объект для навигации для объектов наследуемых от одного базового класса. Он же будет выбирать индекс выборки , считывать данные, в объект и накладывать блокировки если нужно или возложить эту обязанность на сам объект. Внутри этих объектов будет творится очень много действий, но выглядеть это будет как обычный объект
Бррррр, к чему все это?
Механика хранения и доставания, на этом этапе, не имеет никакого смысла, давай плясать от свойств объекта.
S> Опять же. Сначало нужно плясать от форматов хранения данных. Константа может представлять собой некую запись в таблице или Блоб данные.
Зачем? Формат в общем случае не важен. Константа — она и в африке константа.
S> Можно абстракто описать модель, но она должна базироваться уже на какойто модели хранения данных
Да не нужна пока никакая модель. Пусть в первом приближении модель будет такая, как нам удобно. Как именно это будет храниться и как доставаться не важно абсолютно.
S> Тогда это плохо продуманный объект. Всегда можно и нужно на этапе разработки продумать все возможные алгоритмы выборки (не так их уж и много) но уже дальше плясать только от них.
Если мы пишем универсальное хранилище, то мы просто не можем предположить, какие именно алгоритмы и в каких объектах будет использовать потребитель нашего хранилища.
Ты же не предлагаешь писать каждый раз хранилище конкретно под каждую систему? Значит хранилище ничего об объекте не знает.
S> Выше объснял, что доступ осуществляется через свойства, которые должны гарантировать актуальность результатов.
За счет чего? Есть Get, есть Set. Допустим результат Get мы запомнили. Потом вызвали Set, и результат вызова Get будет другой, как база узнает, что Get поменялся? Даже объект знает, что поменялись лишь приватные поля, а вызовы каких методов при этом изменились — не известно.
Здравствуйте, Merle, Вы писали:
S>> Выше объснял, что доступ осуществляется через свойства, которые должны гарантировать актуальность результатов. M>За счет чего? Есть Get, есть Set. Допустим результат Get мы запомнили. Потом вызвали Set, и результат вызова Get будет другой, как база узнает, что Get поменялся? Даже объект знает, что поменялись лишь приватные поля, а вызовы каких методов при этом изменились — не известно.
Вот как раз в вызовах Get и Set все взаимодействия с БД и прописываются, а не только простой доступ к полям.Так же как это делает SQL за счет блокироврк итд
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Вот как раз в вызовах Get и Set все взаимодействия с БД и прописываются, а не только простой доступ к полям.
Кем прописывается, разработчиком? Это получается реализация БД в рукопашную, кому это надо?. К тому же в этих методах еще и считать приходится. Проще как сейчас, в ручную распихать по табличкам, а потом собрать — так реляционный движек на себя всю рутину возьмет.
В идеале разработчик ничего не должен знать о том как, где, и за счет чего объект будет храниться. Максимум в нужных местах вызывается метод типа .Persist() и все, на этом ручное взаимодействие с базой заканчивается.
S> Так же как это делает SQL за счет блокироврк итд
Только у SQL'я для этих блокировок куча полезных вещей имеется и центральный менеджер, который все разруливает, а что в замен?
Здравствуйте, Аноним, Вы писали:
А>я сдаюсь !
Уважаю людей, которые открыто признают свои ошибки.
А>да Мерле вы меня убедили — ваши доводы информативны и бесспорны (Как хорошо показывает практика)
Угу, оценки сообщений, как правило, с достаточной степенью достоверности отражают мнение аудитории. Так что Ваша правда.
А> а аргументы убедительны
И тут нечего возразить, мы с Вами сегодня на удивление солидарны..
А>(нет ответа — топик переносится)
Честное слово это не я. Зарегистрированным пользователям, на сайте доступна так называемая "автомодерилка". Пользователи могут проголосовать за перенос того или иного топика в другой форум, если в текущем он им кажется оффтопиком. И если суммарный рейтинг проголосовавших за перенос выше какого-то порога, то топик переносится автоматически, без участия модератора, что и произошло в данном случае.
Я, честно говоря, хотел бы часть сообщений вернуть обратно, но поскольку в этом форуме я не модератор, то придется просить команду.
А> и подверждены ссылками на тесты и компетентные источники.
Безусловно, рад, что Вы наконец-то это признали.
А>(матом не дают, посты исчезают)
Естественно, это запрещено правилами сайта. Более того, это так же грозит закрытием доступа на сайт.
Вообще, если есть какие-то претензии к модерированию, то Вы всегда можете послать сообщение на moderator@rsdn.ru, с описанием сути Вашего недовольства. Нас около 20 человек, активных членов RSDN Team, и если команда признает, что в отношении Вас была совершена некая несправедливость, то перед Вами непременно извинятся, восстановят в правах и вернут все сообщение на надлежащие по Вашему мнению места.
А>вы открыли мне глаза
Всегда рад.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, theOne, Вы писали:
O>>Не вижу какая трудность по сохранению объектов и извлечению таковых? M>Нууу.. В твоем примере нет M>1. Наследования M>2. Инкапсуляции M>3. Полиморфизма M>То есть, с точки зрения ООП, здесь и не объекты вовсе, а структуры. Я уже не говорю о виртуальных методах и прочих тонких материях.
Не буду спорить с тобой, поскольку ты прав, я же хотел контекстно намекнуть, что Оракл пытается сделать и что у него начинает появляться подобие хранения объектов, знаю что много еще надо сделать — даже одно из простейших: после создания CREATE TABLE .. OF sometype изменить или удалить тип при существующей таблице ну никак нельзя, но я не о этом. Просто по времени, пока microsoft будет делать что-то новое, то Оракл может уже сделает что-нибудь с поддержкой объектов.
Хотя мне все это по барабану. Поскольку в настоящее время меня MSSQL Server устраивает и хорошо, что он прост как две копейки. Если, что и просят сделать я громогласно заявляю: "Это же MSSQL!". Так, что в этом отношении все ОК.
Здравствуйте, Vasiliy_Krasnokutsky, Вы писали:
V_K>Добрый день, V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql. V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных. V_K>Желательно бы ссылки на статьи или книги.
V_K>Заранее благодарен, Краснокутский Василий
В одном из прошлых проектов использовали Oracle + .Net. Была проблема — в oraclt полностью отсутствовал механизм распределенных транзакций. Это не позволило использовать COM+...
Возможно с тех пор проблему решили, я не интересовался...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Вот как раз в вызовах Get и Set все взаимодействия с БД и прописываются, а не только простой доступ к полям. M>Кем прописывается, разработчиком? Это получается реализация БД в рукопашную, кому это надо?. К тому же в этих методах еще и считать приходится. Проще как сейчас, в ручную распихать по табличкам, а потом собрать — так реляционный движек на себя всю рутину возьмет. M>В идеале разработчик ничего не должен знать о том как, где, и за счет чего объект будет храниться. Максимум в нужных местах вызывается метод типа .Persist() и все, на этом ручное взаимодействие с базой заканчивается.
S>> Так же как это делает SQL за счет блокироврк итд M>Только у SQL'я для этих блокировок куча полезных вещей имеется и центральный менеджер, который все разруливает, а что в замен?
А в замен, все эти механизмы должны быть в самой БД встроены, что по сути не так и сложно. Тот же центральный менеджер может выполнять ту же работу только на объектном уровне. И какая разница разбирать SQL запрос или Некий алгоритм написанный с применением объектов ???? Во всяком случае для локальных БД это все легко прописывается автоматом. А SQL еще сидит на уровне 70 годов.
А те подвижки которые есть в Юкон нельзя назвать революционными. А вот пример SQLJ мне очень понравился.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А в замен, все эти механизмы должны быть в самой БД встроены, что по сути не так и сложно. Тот же центральный менеджер может выполнять ту же работу только на объектном уровне.
Да в том-то и дело, что невозможно выполнять ту же работу на объектном уровне, с той же эффективностью. Причем производительность падает в разы, почему — см. топики выше.
S>И какая разница разбирать SQL запрос или Некий алгоритм написанный с применением объектов ????
Разобрать — не проблема, проблема в том, что объект надо достать, а чтобы определить нужный ли он — необходимо вызвать метод этого объекта, что убивает производительность напроч.
S>Во всяком случае для локальных БД это все легко прописывается автоматом.
Агащазблин. Автоматом это прописывается, если ты пишешь БД под конкретную систему, а если нет, опять-таки см. выше. К тому же локальные БД сейчас мало кого интересуют.
S> А SQL еще сидит на уровне 70 годов.
А почему так, никогда не задумывался? До тех пор, пока хранилище само по себе реляционное, все самые эффективные способы работы с этим хранилищем будут оставаться реляционными.
Причем производительность здесь очень критичный параметр. Если в обычной программе падение производительности на 10-20% пользователь и не заметит, то в БД это не так.
По этому поводу приводился очень хороший пример: Если OLAP куб перестраивается с ноля часов до семи утра, то недостаток перфоманса выливается в неуспевчик к началу рабочего дня. И банальной железкой помощнее тут не отделаешься.
S> А те подвижки которые есть в Юкон нельзя назвать революционными.
А ничего революционного никто не обещал.
S>А вот пример SQLJ мне очень понравился.
Тот же SQL, только в профиль. То, что раньше делалось на клиенте или в среднем звене — теперь делается на сервере, но реляционная суть не изменилась. Те же реляционные запросы к хранилищу, опять-таки ничего революционного.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> А в замен, все эти механизмы должны быть в самой БД встроены, что по сути не так и сложно. Тот же центральный менеджер может выполнять ту же работу только на объектном уровне. M>Да в том-то и дело, что невозможно выполнять ту же работу на объектном уровне, с той же эффективностью. Причем производительность падает в разы, почему — см. топики выше.
Интересно на локальных базах можно а на SQL нельзя??? Если туже таблицу рассматривать как коллекцию данных объекта являющимся одним их его его полей(а не объектов как таковых), то все прекрасно описывается не нужна никакая сериализация, т.к. запись просто считывается в объект итд.
И никаких потерь (запись можно и не считывать а держать ссылку на нее)
S>>И какая разница разбирать SQL запрос или Некий алгоритм написанный с применением объектов ???? M>Разобрать — не проблема, проблема в том, что объект надо достать, а чтобы определить нужный ли он — необходимо вызвать метод этого объекта, что убивает производительность напроч.
Интересно, насколько вышеописанный подход убьет все напрочь ????? S>>Во всяком случае для локальных БД это все легко прописывается автоматом. M>Агащазблин. Автоматом это прописывается, если ты пишешь БД под конкретную систему, а если нет, опять-таки см. выше. К тому же локальные БД сейчас мало кого интересуют.
С точки зрения хранилища данных чем SQL отличается от любой локальной БД???? S>> А SQL еще сидит на уровне 70 годов. M>А почему так, никогда не задумывался? До тех пор, пока хранилище само по себе реляционное, все самые эффективные способы работы с этим хранилищем будут оставаться реляционными. M>Причем производительность здесь очень критичный параметр. Если в обычной программе падение производительности на 10-20% пользователь и не заметит, то в БД это не так. M>По этому поводу приводился очень хороший пример: Если OLAP куб перестраивается с ноля часов до семи утра, то недостаток перфоманса выливается в неуспевчик к началу рабочего дня. И банальной железкой помощнее тут не отделаешься.
Во во а может алгоритмы пересмотреть, если конечно речь не идет о миллиардах записей. На самом деле очень много поменялось с того времени особенно в железе и нужно применять другие подходы. S>> А те подвижки которые есть в Юкон нельзя назвать революционными. M>А ничего революционного никто не обещал.
S>>А вот пример SQLJ мне очень понравился. M>Тот же SQL, только в профиль. То, что раньше делалось на клиенте или в среднем звене — теперь делается на сервере, но реляционная суть не изменилась. Те же реляционные запросы к хранилищу, опять-таки ничего революционного.
Не скажи. Применение объектных запросов это уже новая высокоуровневая абстракция, хотя если рассмативать конечный алгоритм выполнения запросов то на этом уровне отличия от локальных БД нет, конечно не беря во внимание внутренне устройство. Только в Локальных БД все эти алгоритмы прописываются ручками или своим придуманным автоматом.
Премущество SQL в краткой записи алгоритма, который затем разбрасывается на элементарные куски,
а для объектного подхода нужно разрабатывать свой синтаксис. А может он и не нужен. Когда ведется спор, что в SQL более краткая запись,то когда рука набита лишние 5-10 строчек не проблема. Даже без статистики собираемой SQL (при определенных условиях даже не нужная)
Только в SQL этого еще очень долго не будет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Интересно на локальных базах можно а на SQL нельзя??? M>Да и на локальных-то не особо льзя.
S>>Если туже таблицу рассматривать как коллекцию данных объекта являющимся одним их его его полей(а не объектов как таковых), то все прекрасно описывается не нужна никакая сериализация, т.к. запись просто считывается в объект итд. M>Объект — это не только набор полей. Набор полей — это структура, а объект обладает поведением. И пока не вызовешь метод объекта, что означает набор полей объекта — неизвестно.
Объект Это экземпляр класса, единственное его отличие от структуры (в C++ вообще нет разницы, а в Net нет наследование и может быть только в стеке или как поле объекта или элементом массива) это ссылка на VMT или некий ID по которому в некой хэш таблице можно найти адрес VMT данного типа. Все манипуляции с этой структурой идут на основании типа. А из этого следует что если тип известен, то и нет проблем манипулирования с ним. В Net часто приходится использовать массивы структур, для отказа от работы с объектами для ускорения работы и все механизмы БД там присутствуют, только вместо ссылок применяются структура
массив и индекс в массиве по которому получаем доступ к подчиненной записи.
S>> И никаких потерь (запись можно и не считывать а держать ссылку на нее) M>Где держать?
Давай так. Таблица представляет собой коллекцию данных данных объекта. Можно работать считывая данные в поле или поле будет держать ссылку на запись в памяти. Организация работы с данными в SQL состоит в загрузке страниц в память. S>> Интересно, насколько вышеописанный подход убьет все напрочь ????? M>Именно напрочь, вплоть до полной неприменимости в практических задачах.
Ну это не доказуемый спор. S>> С точки зрения хранилища данных чем SQL отличается от любой локальной БД???? M>С той, что в клиент-сервере приходится разруливать многопользовательский доступ.
А на Локальной БД не надо. Тем более речь идет о хранилище данных а не надстройкой над ней. И если я сделаю Свою клиент серверную надстройку над локальной БД с разруливанием многопользовательского доступа на сервере с транзакциями итд то она будет называться SQL ???? S>> Во во а может алгоритмы пересмотреть, если конечно речь не идет о миллиардах записей. M>Думаешь OLAP/OLTP системы полные идиоты разрабатывают? M>Они над эффективными алгоритмами круглыми сутками головы ломают, и уж в таких системах все вылизано до невозможного состояния.
О каких объемах идет речь как в записях так и байтах. Очень интересно смоделировать данную задачу но только ручками с применением других алгоритмов.
S>> Не скажи. Применение объектных запросов это уже новая высокоуровневая абстракция, M>Да нет там объектных запросов. Сам запрос все равно реляционный, хотя и используется из объекта напрямую..
Ну а как ты хотел. На уровне ассемблера ООП тоже не пахнет S>> Премущество SQL в краткой записи алгоритма, который затем разбрасывается на элементарные куски, M>Преимущество SQL не в этом. M>Дело в том, что на данный момент не существует универсального, более-менее эффективного алгоритма отображения любого объекта на реляционную структуру. И пока такового не появится придется работать руками с SQL'ем.
Да я уже сколько только и пишу, что ОО на РБД легко реализуется, единственно возникают проблемы когда полем объекта является неопределенный объект содержащее поле тип
struct НеопределенныйОбъект
{ int TypeID;// тип объекта а значит и таблицы где хранятся его данные
int ID;
}
А вот разбираться с этим простым запросом достаточно проблематично. S>> а для объектного подхода нужно разрабатывать свой синтаксис. M>Он уже давно разработан, читай ODMG (OQL — Object Query Lang..)
К чему толь его применить????
S>> Только в SQL этого еще очень долго не будет. M>Да SQL'ю это и не нужно... С точки зрения объектов SQL — это костыли. Если появится нормальная OODBMS, то об SQL все забудут, как о страшном сне...
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А из этого следует что если тип известен, то и нет проблем манипулирования с ним.
Проблем нет, кроме одной — время.
Приходится манипулировать с каждым экземпляром, чтобы найти нужный. В этом-то и проблема.
S> Ну это не доказуемый спор.
По большому счету да, но отсутствие подобных систем является косвенным подтверждением моих слов.
S> А на Локальной БД не надо. Тем более речь идет о хранилище данных а не надстройкой над ней. И если я сделаю Свою клиент серверную надстройку над локальной БД с разруливанием многопользовательского доступа на сервере с транзакциями итд то она будет называться SQL ????
Она будет называться "клиент-серверная надстройка". Не надо никаких надстроек.
В обязанности реляционной БД входит разруливание многопользовательского доступа.
S> О каких объемах идет речь как в записях так и байтах. Очень интересно смоделировать данную задачу но только ручками с применением других алгоритмов.
В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу.
S> Ну а как ты хотел. На уровне ассемблера ООП тоже не пахнет
Но из C'шных объектов в ассемблер переводит компилятор, а тут все равно пишешь руками реляционные запросы.
S> Да я уже сколько только и пишу, что ОО на РБД легко реализуется,
Ну а я тебе пишу, что легко реализуется хранилище под конкретную систему, без большой конкурирующей нагрузки, а универсально — нет. Да и это "легко" — достаточно условно.
S> К чему толь его применить????
А это уже другой вопрос.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> А из этого следует что если тип известен, то и нет проблем манипулирования с ним. M>Проблем нет, кроме одной — время. M>Приходится манипулировать с каждым экземпляром, чтобы найти нужный. В этом-то и проблема.
S>> Ну это не доказуемый спор. M>По большому счету да, но отсутствие подобных систем является косвенным подтверждением моих слов.
S>> А на Локальной БД не надо. Тем более речь идет о хранилище данных а не надстройкой над ней. И если я сделаю Свою клиент серверную надстройку над локальной БД с разруливанием многопользовательского доступа на сервере с транзакциями итд то она будет называться SQL ???? M>Она будет называться "клиент-серверная надстройка". Не надо никаких надстроек. M>В обязанности реляционной БД входит разруливание многопользовательского доступа.
На уровне Файл сервера с блокировками на уровне файла или Клиент сервера на абсолютно другом уровне с применением критических секций итд. Разница очень большая. S>> О каких объемах идет речь как в записях так и байтах. Очень интересно смоделировать данную задачу но только ручками с применением других алгоритмов. M>В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу.
Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек. А учитывая Кэши Raid массивов и их пропускной способности уложится в часы нужно сильно постараться. S>> Ну а как ты хотел. На уровне ассемблера ООП тоже не пахнет M>Но из C'шных объектов в ассемблер переводит компилятор, а тут все равно пишешь руками реляционные запросы.
А запрос куда переводится???? Теже Б деревья, Хэш таблицы итд наверное компилируются, иначе скорость выполнения запроса была бы как на Аксессе. В данном случае можно говорить о неком компилируемом языке, использующий оптимизатор запросов и статистику. Кстати данный подход применяется и в Net и Java.
S>> Да я уже сколько только и пишу, что ОО на РБД легко реализуется, M>Ну а я тебе пишу, что легко реализуется хранилище под конкретную систему, без большой конкурирующей нагрузки, а универсально — нет. Да и это "легко" — достаточно условно.
Универсальную можно только на уровне SQL и ооочень примитвного использования ОО.
А может системы аля 1С только на уровне Сервера применимы ???? Не даром у M$ большие планы в данном направлении. Поживем увидим. Все равно ничего не остается делать, и копаться в Юкон.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> На уровне Файл сервера с блокировками на уровне файла или Клиент сервера на абсолютно другом уровне с применением критических секций итд. Разница очень большая.
Да какая разница на каком уровне, ты опять залез в конкретную реализацию. Просто по определению, чтобы иметь право называться СУБД система должна уметь разруливать параллельный доступ к данным.
M>>В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу. S> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек. А учитывая Кэши Raid массивов и их пропускной способности уложится в часы нужно сильно постараться.
Ты хорошо себе представляешь, что такое OLAP и каким образом там кубы считаются? Это не массив int'ов, проиндексированый. Там очень большая избыточность, куб формируется из относительно небольшой OLTP системы, таким образом, чтобы последующие запросы к нему не требовали практически никаких объединений. И этот процесс занимает несколько часов. Зато когда на утро приходят клиенты и манагеры, запросы на чтение по такой системе летают не за 10 сек, а гораздо меньше.
S> А запрос куда переводится???? Теже Б деревья, Хэш таблицы итд наверное компилируются, иначе скорость выполнения запроса была бы как на Аксессе.
Компиляция запроса занимает вообще смешное время, дороже всего обходится расчет оптимального плана выполнения, поэтому планы кешируются.
S> В данном случае можно говорить о неком компилируемом языке, использующий оптимизатор запросов и статистику.
Так в том-то и фокус, что для объектов напрямую, минуя реляционную стадию, неьзя такого придумать. Точнее может и можно, но пока никто не додумался.
M>>>В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу. S>> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек. А учитывая Кэши Raid массивов и их пропускной способности уложится в часы нужно сильно постараться. M>Ты хорошо себе представляешь, что такое OLAP и каким образом там кубы считаются? Это не массив int'ов, проиндексированый. Там очень большая избыточность, куб формируется из относительно небольшой OLTP системы, таким образом, чтобы последующие запросы к нему не требовали практически никаких объединений. И этот процесс занимает несколько часов. Зато когда на утро приходят клиенты и манагеры, запросы на чтение по такой системе летают не за 10 сек, а гораздо меньше.
Да прекрасно я себе ее представляю. А пример привел для соотношеня скоростей. Просто в SQL и страница под страницу индекса составляет 8 кб а это тормоза на вставку, да и в качестве таблицы лучше применять Хэш таблицу а не кластерный индекс. Руками все это очень легко реализуется. Вообще в SQL именно на вставку модификацию работает сравнительно плохо.
Кстати для смеха проводили тест 100 тыс записей по 400 байт как аналог кластерного индекса за 1.6 секунды, на дженериках типа Б+ деревьях типа Key,Value S>> А запрос куда переводится???? Теже Б деревья, Хэш таблицы итд наверное компилируются, иначе скорость выполнения запроса была бы как на Аксессе. M>Компиляция запроса занимает вообще смешное время, дороже всего обходится расчет оптимального плана выполнения, поэтому планы кешируются.
Ну ясен пень не каждый же раз компилировать. А теперь представь ситуацию когда ты сам пишешь весь план запроса ручками и компилируется быстро или берется уже скомпилированный алгоритм. А вот в Аксессе такого нет. Особенно для сложных алгоритмов. S>> В данном случае можно говорить о неком компилируемом языке, использующий оптимизатор запросов и статистику. M>Так в том-то и фокус, что для объектов напрямую, минуя реляционную стадию, неьзя такого придумать. Точнее может и можно, но пока никто не додумался.
Так в том то и суть, что этого и не нужно (Вернее на данном этапе) и полностью использовать все наработки РБД но на новый лад. Но о чем можно говорить если даже в Юконе в ХП нельзя использовать объекты. А насчет додуматься то уверяю что наработок скорей всего очень много, а вот изменить ооочень сложную систему то на это потребуется огромное количество времени и сил. Все пока идет эволюционным путем, но все же идет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек.
Вот, кстати, вспомнился простенький тестик... Допустим есть 1000000 интов, монотонно возрастающих. В них 1000 разрывов. за сколько твоя система выдаст начало и конец каждого непрерывного участка?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек.
M>Вот, кстати, вспомнился простенький тестик... Допустим есть 1000000 интов, монотонно возрастающих. В них 1000 разрывов. за сколько твоя система выдаст начало и конец каждого непрерывного участка?
Ну обычным пробегом за сотые доли секунды. Кстати разбор текста на строки 150 MB 10 милионов строк без выделения менее 2 сек, с выделение 3 сек.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Да прекрасно я себе ее представляю. А пример привел для соотношеня скоростей. Просто в SQL и страница под страницу индекса составляет 8 кб а это тормоза на вставку,
С какой стати? Ты предлагаешь размер страницы равный размеру записи делать?
S> да и в качестве таблицы лучше применять Хэш таблицу а не кластерный индекс.
Ага лучше, если эта таблица в память влезает. А если не влезает, то труба. А в БД она по определению не влезает.
S> Руками все это очень легко реализуется. Вообще в SQL именно на вставку модификацию работает сравнительно плохо.
По сравнению с чтением — конечно.
S> А теперь представь ситуацию когда ты сам пишешь весь план запроса ручками и компилируется быстро или берется уже скомпилированный алгоритм.
А ты представь ситуацию, когда у тебя оптимальный план меняется от запроса к запросу, а тот что был оптимальным в прошлый раз — сейчас один из самых тормозных.
Вот в таких ситуациях БД и выручает грамотно собранная статистика в компании с хорошим оптимизатором. Само руками такое в принципе не делается.
S> Но о чем можно говорить если даже в Юконе в ХП нельзя использовать объекты.
Почему нельзя? берешь любой Net язык и вперед...
Здравствуйте, Serginio1, Вы писали:
S> Ну обычным пробегом за сотые доли секунды. Кстати разбор текста на строки 150 MB 10 милионов строк без выделения менее 2 сек, с выделение 3 сек.
Это ты проверил или на вскидку сказал? Или ты под каждую задачу оптимальный алгоритм реализуешь?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Да прекрасно я себе ее представляю. А пример привел для соотношеня скоростей. Просто в SQL и страница под страницу индекса составляет 8 кб а это тормоза на вставку, M>С какой стати? Ты предлагаешь размер страницы равный размеру записи делать?
Нет конечно тем более записи. Размер страницы индекса должен подбираться для оптимальной скорости вставки. Но это впрочем не важно, т.к. основная скорость на чтение а там как раз высота дерева более критична.
S>> да и в качестве таблицы лучше применять Хэш таблицу а не кластерный индекс. M>Ага лучше, если эта таблица в память влезает. А если не влезает, то труба. А в БД она по определению не влезает.
Ну зачем сразу в память. На диск, все равно файл кэшируется на уровне системы, хотя и ручками можно постранично держать в памяти. S>> Руками все это очень легко реализуется. Вообще в SQL именно на вставку модификацию работает сравнительно плохо. M>По сравнению с чтением — конечно.
S>> А теперь представь ситуацию когда ты сам пишешь весь план запроса ручками и компилируется быстро или берется уже скомпилированный алгоритм. M>А ты представь ситуацию, когда у тебя оптимальный план меняется от запроса к запросу, а тот что был оптимальным в прошлый раз — сейчас один из самых тормозных.
На самом деле таких ситуаций очень мало, и сколько нужно статистики например для 100 000 товаров, где то прямое чтение всех записей а где то и другой подход. Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам. M>Вот в таких ситуациях БД и выручает грамотно собранная статистика в компании с хорошим оптимизатором. Само руками такое в принципе не делается.
S>> Но о чем можно говорить если даже в Юконе в ХП нельзя использовать объекты. M>Почему нельзя? берешь любой Net язык и вперед...
Использую Хэш таблицы итд ????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Ну обычным пробегом за сотые доли секунды. Кстати разбор текста на строки 150 MB 10 милионов строк без выделения менее 2 сек, с выделение 3 сек. M>Это ты проверил или на вскидку сказал? Или ты под каждую задачу оптимальный алгоритм реализуешь?
Проверил Вот сдесь результаты тестов http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019
Также исходники объектов для последовательного чтения текстовых файлов
как в прямом так и в обратном направлении TTextReader и TTextBackReader использующие кольцевой буффер размером 64 кб с ограничением на длину строки 64 кб — 3 байта.
Сразу предупреждаю, что не протестированы на все граничные условия.
А то народ через стринглист все читает, особенно много вопросов а как прочитать 9000 запись с начала или с конца. Вот и сделал простенькие объекты для чтения и записи и сравнил со стандартными. Правда эти результаты на откэшированных файлах.
и солнце б утром не вставало, когда бы не было меня
Re[35]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
14.01.04 22:11
Оценка:
может кто все же догадается посмотреть на промышленые реализации ?
1. на как и чем крутится Lotus Notes — это не RDBMS, но есть вариант что под низом у нее все таки DB2.
2. как и где работает промышленая ООСУБД Cashe
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Размер страницы индекса должен подбираться для оптимальной скорости вставки. M>Ну тоже достаточно спорно, от задачи зависит...
S>> Ну зачем сразу в память. На диск, все равно файл кэшируется на уровне системы, хотя и ручками можно постранично держать в памяти. M>И вот тут-то все достоинства хеш-таблиц дружно присядут. Поскольку по диску придется елозить гораздо больше, чем при B+дереве и в менее предсказуемом режиме, а дисковые операции самые дорогие. M>А если еще и про многопользовательскую работу вспомнить — то вообще труба.
Ну ну. Какое елозание если страницы кэшированы в памяти. А на Б+ дереве как бы там не было а в зависимости от количества уровней обратится придется еще больше, т.к. в среднем за 1.3 попытки находится результат в Хэш таблице. плюс Log(N) сравнений.
S>> На самом деле таких ситуаций очень мало, и сколько нужно статистики например для 100 000 товаров, где то прямое чтение всех записей а где то и другой подход. M>И ситуаций гораздо больше чем кажется, и усредненные алгоритмы серьезно проигрывают оптимальным. Все-таки БД сейчас не зря такие, какие они есть.
Все зависит от ситуации. Тоесть собирается вся статистика по всем 100 000 для различный запросов ????? Да там статистика больше базы будет которая кто му же сильно меняется.
S>>Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам. M>Ну вот это ты не прав. Выигрыш от правильного использования статистики существенно больше чем издержки на ее своевременное поддержание.
Очень спорно, все зависит от ситуации. Значит ты не веришь в теориЮ Вероятностей??? S>> Использую Хэш таблицы итд ???? M>А что, ты хотел движек БД напрямую из хранимок пользовать?
Нет конечно, но промежуточные результаты вполне возможно вычислять. Или это прерогатива только клиента ????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>По-моему разговор съезжает с темы. Давай вернемся немного назад. Вот сюда: S>
S>Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
S>
S>Это гипотетический язык. Семантика ясна? На всякий случай я поясню: мы хотим найти множество всех объектов, которые реализуют интерфейсы IAmountable и ISecuredObject. При этом значение, возвращаемое методом IAmountable.Amount() должно превышать 100, а метод ISecuredObject.AllowsAccess() должен возвращать "истина" при передаче ему в качестве параметра менеджера текущего пользователя. S>В базе живет, скажем, N ~ 1e7 объектов. Интерфейс ISecuredObject реализован примерно в 300 из 1000 зарегистрированных классов; интерфейс IAmountable — в 20. Одновременно с системой работают на R/W 50 пользователей, на R 500. S>Ты не мог бы ответить на несколько простых вопросов (не вдаваясь в технические детали): S>1. Каким образом будет выглядеть план этого запроса? S>2. Какова ожидаемая зависимость быстродействия этого запроса от N? S>3. Каким образом можно построить этот план, имея на входе декларативное описание запроса, вроде вышеописанного? Учитывая то, что вообще говоря есть инкапсуляция, т.е. все состояние объекта помечено как private.
А пробежаться по метаданным, и запросить у типа поддерживает ли он некий интерфейс и являются ли эти юзеры манагерами. Банальный перебор. А 1e7 типов очень проблематично вообще сделать. В данном случае опять опираясь на реляционные или еще какие БД то данные объектов хранятся в одном своем хранилище и нужно проверить соответствие только у типа и если оно правильно просто запросить количество экземпляров этого типа. S>Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым.
Может я, что то не правильно объяснил????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S> А пробежаться по метаданным, и запросить у типа поддерживает ли он некий интерфейс и являются ли эти юзеры манагерами. Банальный перебор.
Хм. Ну пробежались мы. Хорошо, оба интерфейса поддерживаются 20 классами. У нас есть список этих классов, полученный (пока что) линейным перебором. На таких количествах большого смысла делать супероптимизации нет. Поехали дальше. S>А 1e7 типов очень проблематично вообще сделать.
Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета. S>В данном случае опять опираясь на реляционные или еще какие БД то данные объектов хранятся в одном своем хранилище и нужно проверить соответствие только у типа и если оно правильно просто запросить количество экземпляров этого типа.
Видишь ли, нам надо не количество экземпляров типа. Пусть их оказалось, скажем, 50000 (всех 20 классов меньше взятых) Надо узнать, какие из этих экземпляров удовлетворяют предикату. Про это у тебя ни слова нет. S>>Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым. S> Может я, что то не правильно объяснил????
Да ты пока еще ничего не объяснил. Продолжай. Расскажи мне, каким алгоритмом мы будем выполнять запрос.
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
15.01.04 10:06
Оценка:
А>>2. как и где работает промышленая ООСУБД Cashe А>Ага ОО.. Где там эти две буквы? Даже сами хлопцы из интерсустемса аккуратненько называют ее "постреляционная", так как не смотря на все потуги она ни какая не объектная, а очень хорошо написанная иерархическая БД. Ну максимум сетевая.
вы наверно на сайт даже зашли
но все же надо было бы чуть ниже посмотреть ... там как раз о том что же они постреляционным называют ...
4. Adoption of a Post-Relational Database
Post-relational (a.k.a., transactional multidimensional) databases such as Caché implement an associative array technology that can be projected to an object or relational model simultaneously and without intervening mapping tools or caching middle tiers.
Здравствуйте, Аноним, Вы писали:
А>вы наверно на сайт даже зашли
Ххха! зашел..
А>но все же надо было бы чуть ниже посмотреть ...
Нееее, ниже не надо.
На кой фиг мне на их сайт смотреть, если я на ней работал?
А>Post-relational (a.k.a., transactional multidimensional) databases such as Caché implement an associative array technology that can be projected to an object or relational model simultaneously and without intervening mapping tools or caching middle tiers.
Как тут кто-то очень верно заметил, словом "объект" кидаются все кому не лень, но никто не понимает, что это такое. Все тока чувствуют, но словами никто сказать не может. Так что я тут могу вполне авторитетно заявить — объектного в ней только несколько строчек в рекламных статьях.
А>P.s. про лотус попозже ...
Any time.
У меня как раз лотусятник тока-тока с ИБМ-овского семинара вернулся.
Здравствуйте, Vasiliy_Krasnokutsky, Вы писали:
V_K>Добрый день, V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql. V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных. V_K>Желательно бы ссылки на статьи или книги.
V_K>Заранее благодарен, Краснокутский Василий
Что там Oracle & SQLServer, я вот слышал что на новом круизном лайнере (тот который побольше Титаника) Progress RDBMS поставили — вот это круто
Так что Oracle & SQLServer — вчерашний день
Теперь можно смело ждать очередного айсберга и пышных похорон
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> А пробежаться по метаданным, и запросить у типа поддерживает ли он некий интерфейс и являются ли эти юзеры манагерами. Банальный перебор. S>Хм. Ну пробежались мы. Хорошо, оба интерфейса поддерживаются 20 классами. У нас есть список этих классов, полученный (пока что) линейным перебором. На таких количествах большого смысла делать супероптимизации нет. Поехали дальше. S>>А 1e7 типов очень проблематично вообще сделать. S>Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета. S>>В данном случае опять опираясь на реляционные или еще какие БД то данные объектов хранятся в одном своем хранилище и нужно проверить соответствие только у типа и если оно правильно просто запросить количество экземпляров этого типа. S>Видишь ли, нам надо не количество экземпляров типа. Пусть их оказалось, скажем, 50000 (всех 20 классов меньше взятых) Надо узнать, какие из этих экземпляров удовлетворяют предикату. Про это у тебя ни слова нет.
Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
Ну простым перебором по 50000 это вообще милисекунды. А если ISecuredObject.AllowsAccess((Context.User as Employee).Manager)==false то вообще бегать.
S>>>Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым. S>> Может я, что то не правильно объяснил???? S>Да ты пока еще ничего не объяснил. Продолжай. Расскажи мне, каким алгоритмом мы будем выполнять запрос.
Учитывая, что за выборку отвечает некий объект, считывая данные в поле объекта. Все очень просто.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Sinclair, Вы писали:
S>>Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета.
AVK>Вот к примеру кондитерская фабрика. В среднем ок. 100 позиций в накладной, ок. 200 накладных в сутки (оптовые продажи). При минимальной 3-хскладовой системе имеем 5 накладных (прих., расх., 2 перемещения). Итого 100 тыс. записей в сутки. Хранить в оперативной БД нужно данные минимум за пару лет. AVK>100тыс. * 365 * 2 это почти 1е8. И это довольно скромная оценка. Предлагаю взять 1е9 записей как верхнюю оценку.
Да хоть 1е10. Суть от этого не меняется. Мыже говрим о данных объекта которое может считываться в поле или другим методом доступ к полям через Inline свойства и хранится в обычной таблице.
Тот же скомпилированный проход как и при SQL.
JIT тоже очень хорошо оптимизирует выборки. А вот разруливание сложных ситуаций например с неопределенными типами полей и виртуальной сущности уже ложится полностью на объект. И максимум замедление при этом будет в 2 раза зато гибкость трудно посчитать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну ну. Какое елозание если страницы кэшированы в памяти.
Память — не резиновая, а ты вынужден весь хеш в памяти держать.
S> А на Б+ дереве как бы там не было а в зависимости от количества уровней обратится придется еще больше, т.к. в среднем за 1.3 попытки находится результат в Хэш таблице. плюс Log(N) сравнений.
Давай считать. Хеш таблица на кучу записей в памяти. Пришел другой запрос, к другой большой таблице. Две в память уже не влезают, по частям хеш-таблицу выгружать смысла не имеет, поэтому она вся из памяти выкидывается и подгружается новая, тоже целиком.
B-Tree же позволяет работать только с частью индекса, в итоге дисковыс операций существенно меньше.
На виртуальную память надеяться не стоит, при таких интенсивных нагрузках — это очень не эффективный механизм, поэтому все БД от виртуальной памяти бегают и берут ее функции на себя.
И еще один момент, про который ты забываешь. B+Tree индекс — отсортирован, а хешь нет. Это означает, что параллельные запросы по одному и тому же B-tree индексу, гарантировано обходят записи в одном и том же порядке, а при изменениях позволяют реализовать очень эффективный механизм блокировок на DAG'ах.
В случае же хеша, порядка доступа никто не гарантирует, что неизбежно будет приводить к дедлокам.
Таким образом, если в грамотно спроектированной системе на Б-дереве можно гарантировать отсутствие дедлоков, то в системе на хеш индексах
не смотря на все усилия разработчика, такого гарантировать нельзя. В принципе эта проблема решаема, но нафиг надо...
S> Все зависит от ситуации. Тоесть собирается вся статистика по всем 100 000 для различный запросов ????? Да там статистика больше базы будет которая кто му же сильно меняется.
Ну статистика же не в тупую собирается, а с умом...
S>>>Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам.
Хха. Джоин двух больших таблиц в одной из которых предикату удовлетворяют 10 записей, а в другой 100000 очень сильно зависит от порядка в каком ты этот джойн будешь делать. А без статистики правильный порядок не угадаешь.
S> Очень спорно, все зависит от ситуации. Значит ты не веришь в теориЮ Вероятностей???
Ну и как теорвер поможет в ситуации описанной выше?
S> Нет конечно, но промежуточные результаты вполне возможно вычислять. Или это прерогатива только клиента ????
Промежуточные результаты чего?
возвращают разумное количество данных). Твой алгоритм будет вынужден честно прокачать 50000/128 = ~390 страниц. Хорошо, предположим отобранные данные занимают еще 10 страниц. Index seek читает 13 страниц, что примерно в 30 раз меньше алгоритма прямого перебора. Неудивительно, что на www.tpc.org не видно и не слышно о результатах ODBMS.
S>А если ты "неким объектом" называешь тот самый оптимизирующий query evaluator — то не скрывай уж от общественности секрет серебряной пули. Черт с ним, алгоритм построителя плана можешь не рассказывать — расскажи сам план, а?
Тяжело отвечать т.к. на данном этапе замучен бухгалтерией, но попытаюсь в кратце. Весь твой пример легко строится на обычных запросах, который генерируется на основании метаданных но с описанных на уровне объектов. А вот другой вопрос по неопределенным типам объекта здесь никакого плана не сделаешь, т.к. тип определяется только на момент получения данных об объекте, а таких ситуаций особенно в бухгалтерии пруд пруди.
Вопрос все 50 000 Amount<100. А построить индекс на все Amount тоже непроблема или вообще на все случаи жизни по всем всевозможным сочитанием полей. При всех записях Amount<100 тебе придется прочитать все данные но через индекс. И вот если Amount не есть поле объекта, а поле подчиненного объекта, то так или иначе придется строить полные вычисления, либо строить совсем другой алгоритм, в зависимости от затрагиваемых объектов (таблиц). И понятно, что такая задача не совсем тривиальна, но вполне вполнима.
А насчет 50 000 вообще не очем говорить.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Ну ну. Какое елозание если страницы кэшированы в памяти. M>Память — не резиновая, а ты вынужден весь хеш в памяти держать.
S>> А на Б+ дереве как бы там не было а в зависимости от количества уровней обратится придется еще больше, т.к. в среднем за 1.3 попытки находится результат в Хэш таблице. плюс Log(N) сравнений. M>Давай считать. Хеш таблица на кучу записей в памяти. Пришел другой запрос, к другой большой таблице. Две в память уже не влезают, по частям хеш-таблицу выгружать смысла не имеет, поэтому она вся из памяти выкидывается и подгружается новая, тоже целиком.
Да смысл Хэш таблицы в том, что за 1 вычисление ты находишь смещение нужной записи, в среднем за 1-1.5 обращения если есть коллизии. И не важно где таблица находится в памяти или на диске, по сравнению с 2-3 тебе придется обратится к диску столько сколько количество уровней. M>B-Tree же позволяет работать только с частью индекса, в итоге дисковыс операций существенно меньше.
Если уровней больше одного то не прав. Правда нужно оговорится, что обычно при частом обращении Root уровень будет всегда в памяти. M>И еще один момент, про который ты забываешь. B+Tree индекс — отсортирован, а хешь нет. Это означает, что параллельные запросы по одному и тому же B-tree индексу, гарантировано обходят записи в одном и том же порядке, а при изменениях позволяют реализовать очень эффективный механизм блокировок на DAG'ах.
Разговор у нас вначале шел о Кубах и их построении. Я утверждаю, что построение их на Хэш таблицах с последющей сортировкой, даст как минимум 4 кратное ускорение если не больше.
M>В случае же хеша, порядка доступа никто не гарантирует, что неизбежно будет приводить к дедлокам.
Почему не блокировать так же как и обычные таблицы по строкам, по страницам итд, причем при рехеше получается 2 таблицы с которыми могут работать разные транзакции. Абсолютно тот же механизм M>Таким образом, если в грамотно спроектированной системе на Б-дереве можно гарантировать отсутствие дедлоков, то в системе на хеш индексах
О хешах следует говорить при их применени для первичных ключей, где сортированность вещь не нужная и для построении группировок с последующей сортировкой.
S>> Все зависит от ситуации. Тоесть собирается вся статистика по всем 100 000 для различный запросов ????? Да там статистика больше базы будет которая кто му же сильно меняется. M>Ну статистика же не в тупую собирается, а с умом...
Согласен, но всех ситуаций не предусмотришь. Обычно это может касеться часто используемых запросов и поностью согласуются с Теорией Вероятностей основанной на статистике.
S>> Нет конечно, но промежуточные результаты вполне возможно вычислять. Или это прерогатива только клиента ???? M>Промежуточные результаты чего?
Часто при проведении документов, нужно вычислять огромое количество результатов, что бы правильно сделать проводки, если делать все с клиента никаких проблем, а еще хотелось бы и в ХП.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
Вот почему-то блокирующие RDBMS не считают это такой тривиальной задачей, и избегают row-level локов поелику возможно. А у нас тут значит рррррррррррраз за миллисекунды выдали 50000 локов, и тут же отдали. Интересно.
Вообще паралелное чтение и запись в любом случае зло, извежать которое можно многим путями которые много раз описывал и имеются в практике. S>Лирическое отступление: OLTP систему нельзя строить на прямом переборе. Масштабируемость никакая! Почему-то даже в случае структур, т.е. не то что VMT — вообще методов нет,
Это кто тебе сказал, что у структур нет методов ??? То, что их нет в SQL это совсем не значит, что их нет. РБД это хранилище структур с описанными связями. И построение ОО над РБД задача если не тривиальная, то вполне выполнимая. И пусть занимется
RDBMS занимаются всякой ерундой — статистикой, индексированием..., как и раньше
А ты утверждаешь, что отказ от этого ухудшит производительность не более чем в 2 раза...
Да утверждаю. Правда при условии, что Amount будет полем обрабатываем таблицы, что легко получить обрабатывая метаданные объекта, которые дополнительно должны быть описаны.
Кстати очень понравилась ECO.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Да смысл Хэш таблицы в том, что за 1 вычисление ты находишь смещение нужной записи, в среднем за 1-1.5 обращения если есть коллизии.
Так тебе надо ее построить в памяти с начала.
S> Разговор у нас вначале шел о Кубах и их построении. Я утверждаю, что построение их на Хэш таблицах с последющей сортировкой, даст как минимум 4 кратное ускорение если не больше.
Ну тут ты совсем неправ. Во первых на таких объемах хеш таблица просто в память не влезет, а во вторых у хеша перед деревом в принципе не такое преимущество — максимум десятки процентов.
S> Почему не блокировать так же как и обычные таблицы по строкам, по страницам итд
Потому что в этом случае нет гарантии, что дедлок не случится.
S>Абсолютно тот же механизм
Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок.
S> О хешах следует говорить при их применени для первичных ключей, где сортированность вещь не нужная и для построении группировок с последующей сортировкой.
Как раз там отсортированность очень прогодилась бы. Скажем запрос where ID>5 при обращении к диску в силу отсортиованности данных будет считываьб последовательные страницы, а в случае хеша — из разных частей диска. Что вообщем тоже для перфоманса не подарок.
Здравствуйте, Serginio1, Вы писали:
S>Тяжело отвечать т.к. на данном этапе замучен бухгалтерией, но попытаюсь в кратце.
Да я не тороплюсь. Так что как разгрузишься — возвращайся S>Весь твой пример легко строится на обычных запросах, который генерируется на основании метаданных но с описанных на уровне объектов.
Все, о чем я тебя прошу — это расшифровать слово "легко". Какие метаданные ты имеешь в виду? S>А вот другой вопрос по неопределенным типам объекта здесь никакого плана не сделаешь, т.к. тип определяется только на момент получения данных об объекте, а таких ситуаций особенно в бухгалтерии пруд пруди.
Не, так мы делаьт не будем. Для упрощения все объекты типизированы статически. S>Вопрос все 50 000 Amount<100. А построить индекс на все Amount тоже непроблема или вообще на все случаи жизни по всем всевозможным сочитанием полей. S> При всех записях Amount<100 тебе придется прочитать все данные но через индекс. И вот если Amount не есть поле объекта, а поле подчиненного объекта, то так или иначе придется строить полные вычисления, либо строить совсем другой алгоритм, в зависимости от затрагиваемых объектов (таблиц).
Это вообще не поле, а метод. Так что только "строить совсем другой алгоритм". S>И понятно, что такая задача не совсем тривиальна, но вполне вполнима.
Ну так ты расскажи — как именно она выполнима? А то я тоже могу сказать, что разложение числа на простые множители быстрее, чем за exp(N), не совсем тривиально, но вполне выполнимо. S> А насчет 50 000 вообще не очем говорить.
Хорошо, пусть будет 50 000 000. Хотя и для 50000, как я тебе показал, разница уже настолько существенная, что никто не станет пользоваться такой системой.
Да, совсем забыл — применение алгоритмоя прямого перебора, помимо очевидного всем, кроме тебя, оверхеда, приносит еще и проблемы с concurrency. Дело в том, что если хотя бы один объект нужного нам класса в данный момент заблокирован на запись, ВСЕ запросы будут курить, пока эта транзакция не завершится. Наличие индексов позволяет одновременно выполнять запросы к тем областям екстента, где нет эксклюзивных блокировок.
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S> Это набор записей, где номер нужной записи получается путем вычисление хэша ключа.
А теперь по номеру записи надо получить ее физический арес на диске.
S>Единственная их проблема это ReHash
Это не единственная проблема, по ночам не сделаешь, достаточно много систем работают 24x7
S>Почему то тесты показывают обратное.
Значит такие тесты.
M>>Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок. S> С такой же вероятностью как и 2-3 (B-tree).
В том то и разница, что в хеше дедлок на одном индексе, а в Б-дереве надо минимум два, что позволяет вообще свести эту вероятность к нулю при грамотном проектировании.
S> Ну такой запрос для первичных ключей мало вообще где используется
Еще как используется.
Здравствуйте, Serginio1, Вы писали:
S> Вообще паралелное чтение и запись в любом случае зло, извежать которое можно многим путями которые много раз описывал и имеются в практике.
Как интересно... Можно ссылочку на описане хотя бы одного путя избежать R/W в OLTP задачах? Например, при резервировании авиабилетов. Выделение каждому пассажиру своей авиакомпании не предлагать. S> Это кто тебе сказал, что у структур нет методов ??? То, что их нет в SQL это совсем не значит, что их нет. РБД это хранилище структур с описанными связями. И построение ОО над РБД задача если не тривиальная, то вполне выполнимая. И пусть занимется
Видишь ли, наличие O/R маппинга опять же не делает из RDBMS OODBMS. Никоим боком. Это всего лишь stateful сервер приложений, интегрированный с RDBMS. Вот Cache хотя бы сделала многомерные индексы... S>RDBMS занимаются всякой ерундой — статистикой, индексированием..., как и раньше S>А ты утверждаешь, что отказ от этого ухудшит производительность не более чем в 2 раза... S> Да утверждаю. Правда при условии, что Amount будет полем обрабатываем таблицы, что легко получить обрабатывая метаданные объекта, которые дополнительно должны быть описаны.
Вот именно. Ты вполне готов строить RDBMS поверх RDBMS. Как, впрочем, и все остальные. То есть, пока поле — это поле, а объект — это запись, все в порядке. можно делать запросы почти так же быстро, как в обычной RDBMS. При условии, что ты будешь пользоваться статистикой и индексированием. Увы, на этом уровне реализовано (в лучшем случае ) наследование. Ни полиморфизма ни инкапсуляции гарантированно нет. А как только мы пытаемся их включить, производительность запросов превращается из M*log(N) в N^M. Где M — количество екстентов в джойне. S>Кстати очень понравилась ECO.
Это кто?
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
M>>Как раз там отсортированность очень прогодилась бы. Скажем запрос where ID>5 при обращении к диску в силу отсортиованности данных будет считываьб последовательные страницы, а в случае хеша — из разных частей диска. Что вообщем тоже для перфоманса не подарок. S> Ну такой запрос для первичных ключей мало вообще где используется т.к. первичный ключ предназначен для связей, а не использоваание его как побочный эффект.
Про первичные ключи — согласен. ODBMS обычно предпочитают хэш-индексы именно потому, что предоставляют в первую очередь traversing, а для него B-tree проигрывает. Возможности range-запросов в них сводят к минимуму, ну либо таки делают деревья для всего остального.
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> ODBMS обычно предпочитают хэш-индексы
Я припоминаю только одну базу, которая пользовала хеш-индекс, но это было что-то древнее, типа клариона и обходилось это неоправдано дорого с точки зрения места на диске, в итоге уже в следующей версии на это дело забили.
Для реляционных баз хеш далеко не лучшее решение, как ни крутись, но при использовании хеш таблиц обмен с диском интенсивнее и меньше поддается оптимизации, и я не очень понимаю, что меняется, если мы начинаем работать с объектами.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Тяжело отвечать т.к. на данном этапе замучен бухгалтерией, но попытаюсь в кратце. S>Да я не тороплюсь. Так что как разгрузишься — возвращайся S>>Весь твой пример легко строится на обычных запросах, который генерируется на основании метаданных но с описанных на уровне объектов. S>Все, о чем я тебя прошу — это расшифровать слово "легко". Какие метаданные ты имеешь в виду?
Давай разберем структуру имеющую поля как числовые, строковые и ссылочные. Обычно это делается через описание полей (заголовочная часть таблицы) и прописания связей в SQL которые по сути и прописывают поведение записей на которых затем и строится запрос. Но возможно делать описание поведения структуры путем введения некоторой большей функциональности. Помоему в клиппере даже хранился скомпилированный код например для вычисления индексного выражения и функции сравнения. S>>А вот другой вопрос по неопределенным типам объекта здесь никакого плана не сделаешь, т.к. тип определяется только на момент получения данных об объекте, а таких ситуаций особенно в бухгалтерии пруд пруди. S>Не, так мы делаьт не будем. Для упрощения все объекты типизированы статически. S>>Вопрос все 50 000 Amount<100. А построить индекс на все Amount тоже непроблема или вообще на все случаи жизни по всем всевозможным сочитанием полей. S>> При всех записях Amount<100 тебе придется прочитать все данные но через индекс. И вот если Amount не есть поле объекта, а поле подчиненного объекта, то так или иначе придется строить полные вычисления, либо строить совсем другой алгоритм, в зависимости от затрагиваемых объектов (таблиц). S>Это вообще не поле, а метод. Так что только "строить совсем другой алгоритм".
Ну я думаю что оптимизатор еще не дошел "строить совсем другой алгоритм", то либо ручками либо в лоб.
Хорошо пусть будет метод, но выборку с учетом индекса тоже можно делать абсолютно не вникая в тонкости. Что в общем то и делаю, но на объектном уровне. Все те же подходы.
Просто для работы с коллекцией данных объекта нужен еще объект для выборки данных, а через него уже управлять использованием индесов при выборке, навигации и блокировок.
S> Наличие индексов позволяет одновременно выполнять запросы к тем областям екстента, где нет эксклюзивных блокировок.
Вот ты сразу о переборе. В задаче не было о них ничего сказано, да и оптимзатор должен пройтись перебором если записях Amount<100 будет больше чем половина. Или я не прав????
А так я только за индексы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Это набор записей, где номер нужной записи получается путем вычисление хэша ключа. M>А теперь по номеру записи надо получить ее физический арес на диске.
Ну а вчем разница от б 2-3 если это не кластерный индекс, что впрочем можно делать и на хэш таблицах. S>>Единственная их проблема это ReHash M>Это не единственная проблема, по ночам не сделаешь, достаточно много систем работают 24x7
Все зависит от условий. Опять же я Хэш таблицу поднял только для использования группирования данных путем хранения в ней Key, Value что соответствуе клястерному инддексу. S>>Почему то тесты показывают обратное. M>Значит такие тесты.
Покажи свои. M>>>Да понятно, что тот же, но в этом случае есть шанс нарваться на дедлок. S>> С такой же вероятностью как и 2-3 (B-tree). M>В том то и разница, что в хеше дедлок на одном индексе, а в Б-дереве надо минимум два, что позволяет вообще свести эту вероятность к нулю при грамотном проектировании.
Не совсем понял, для хэш таблицы я также могу блокировать не только на уровне записи но и на уровне страницы да и всей таблицы, т.к. данные Хэш таблицы тоже хранятся постранично. S>> Ну такой запрос для первичных ключей мало вообще где используется M>Еще как используется.
Ага это выглядит примерно так, выдай мне все объекты адрес которых больше некоторого адреса.
А вот когда для первичных ключей используют испльзуют осмысленный атрибут тогда да.
Но поторюсь Хэш таблицы вылезли при обсуждении использовании их при группировании данных.
и солнце б утром не вставало, когда бы не было меня
S>>Единственная их проблема это ReHash M>Это не единственная проблема, по ночам не сделаешь, достаточно много систем работают 24x7
Это уже другой врпрос. Но например для некотрых наборов записей их количество ограничено и вполне можно применять и Хэш таблицы. Все от ситуации. S>>Почему то тесты показывают обратное. M>Значит такие тесты.
Для примера, приведу индекс CDX в нем придусмотрена сжатие ключей, что бы их поместилось больше на странице и соответственно уменьшения количества обращений к диску и при этом о поиске половинным делением нет и речи. И тормоза.
Не большой вопрос как сказывается увеличение памяти (Athlon 64 вроде как вышел) и применение Raid массивов на производительность.
А вот тесты на памяти дают 4 кратное превосходство Хэш таблиц над Б+ деревьями.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Вот именно. Ты вполне готов строить RDBMS поверх RDBMS. Как, впрочем, и все остальные. То есть, пока поле — это поле, а объект — это запись, все в порядке. можно делать запросы почти так же быстро, как в обычной RDBMS. При условии, что ты будешь пользоваться статистикой и индексированием. Увы, на этом уровне реализовано (в лучшем случае ) наследование. Ни полиморфизма ни инкапсуляции гарантированно нет. А как только мы пытаемся их включить, производительность запросов превращается из M*log(N) в N^M. Где M — количество екстентов в джойне.
Ну ачто делать. Хотя опять ты больше напираешь на массовые запросы. Но иногда и их нужно использовать с применением полиморфизма, когда нужно найти то не зная что. Обычно полиморфизм нужен при неопределенных типах полей и при разветвленных вычислениях со множественными If, где SQL запрос просто не построить.
А разряженные индексы это не проблема. S>>Кстати очень понравилась ECO. S>Это кто?
S> Все зависит от условий. Опять же я Хэш таблицу поднял только для использования группирования данных путем хранения в ней Key, Value что соответствуе клястерному инддексу.
Бррр... Уж для группирования-то хешь зачем использовать? Какой Key-Value, и причем здесь кластерный индекс?
S> Не совсем понял
Еще раз. B tree сортирован, хеш — нет. сортировка позволяет снизить вероятность дедлоков.
S>Но поторюсь Хэш таблицы вылезли при обсуждении использовании их при группировании данных.
Да я вообще не понимаю куда ты хеши впихнуть хочешь. Не смотря на пулеметную скорость, в БД задачах индексы на хеш таблицах использовать не выгодно.
Это может быть выгодно, только в некоторых, довольно редких случаях, при джойнах, и это умеют делать все БД. Если оптимизатор посчитает, что для джойна выгоднее использовать хешь, то сервер его и использует, но держать постоянный хешь индекс смысла не имеет.
S> А вот тесты на памяти дают 4 кратное превосходство Хэш таблиц над Б+ деревьями.
Ну ты пойми, что в реальных системах никогда у тебя не бует такого счастья, как все в памяти.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Вообще паралелное чтение и запись в любом случае зло, извежать которое можно многим путями которые много раз описывал и имеются в практике. S>Как интересно... Можно ссылочку на описане хотя бы одного путя избежать R/W в OLTP задачах? Например, при резервировании авиабилетов. Выделение каждому пассажиру своей авиакомпании не предлагать.
Или при выписке товара. В основном проблемы касаются условно чистого чтения, т.к. даже смомент начала транзакции чтения и ее завершении могут происходить множественные изменения если конечно эти транзакции не последовательны. И стоит ли тратить столько усилий на блокировки и версионное чтение, если можно держать две базы 1 на чтение с синхронизацией много чтецов один писатель, а другая на последовательный доступ для записи с репликацией в базу для чтения с промежутком в 30 сек.
Никаких блокировок, но много ситуаций когда в момент транзакции билетов уже нет. Но возможен вариант когда выбирается не один билет а несколько с приоритетом из которых 1 должен быть обязательно выписан. Вариантов много.
А блокировки с клиента еще большее зло. Хотя ...
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Sinclair, Вы писали:
S>> ODBMS обычно предпочитают хэш-индексы M>Я припоминаю только одну базу, которая пользовала хеш-индекс, но это было что-то древнее, типа клариона и обходилось это неоправдано дорого с точки зрения места на диске, в итоге уже в следующей версии на это дело забили. M>Для реляционных баз хеш далеко не лучшее решение, как ни крутись, но при использовании хеш таблиц обмен с диском интенсивнее и меньше поддается оптимизации, и я не очень понимаю, что меняется, если мы начинаем работать с объектами.
А у нас в RDBMS поиск по точному соответствию — экзотика. Как правило, это все-таки join, а для него merge может быть эффективнее. В ОДБМС, напротив, полагают, что запросы типа id<5 делатья будут редко (если вообще их разрешили), а самые частые — это траверсинг, т.е. вытаскивание 1 объекта по его ID. Даже тесты OO7, афаик, занимаются исключительно навигацией по графу. Никаких поисков по предикатоу (а уж тем более IAmountable) там и не пахнет. Так что в теории вроде сходится. Versant раньше использовал хеши для oid, не знаю что с ними сейчас.
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S> Давай разберем структуру имеющую поля как числовые, строковые и ссылочные. Обычно это делается через описание полей (заголовочная часть таблицы) и прописания связей в SQL которые по сути и прописывают поведение записей на которых затем и строится запрос. Но возможно делать описание поведения структуры путем введения некоторой большей функциональности. Помоему в клиппере даже хранился скомпилированный код например для вычисления индексного выражения и функции сравнения.
Ну, давай разберем. И чем это нам поможет? У нас класс, а не структура! У него методы есть. А поля всех типов — private.
S> Ну я думаю что оптимизатор еще не дошел "строить совсем другой алгоритм", то либо ручками либо в лоб.
Вот приведи мне пример "ручками" S> Хорошо пусть будет метод, но выборку с учетом индекса тоже можно делать абсолютно не вникая в тонкости. Что в общем то и делаю, но на объектном уровне. Все те же подходы.
Как интересно. А что ты используешь в качестве ключа такого индекса? Как ты определяешь момент, когда ключ изменился? S>Просто для работы с коллекцией данных объекта нужен еще объект для выборки данных, а через него уже управлять использованием индесов при выборке, навигации и блокировок.
S>> Наличие индексов позволяет одновременно выполнять запросы к тем областям екстента, где нет эксклюзивных блокировок. S> Вот ты сразу о переборе.
Да не я сразу о перебеоре! Я тебя с самого начала попросил предоставить план выполнения запроса. Ты предложил прямой перебор. Предложи другой план. Только не начиная про "объект, управляющий использованием индексов". Какие индексы ты будешь использовать? S>В задаче не было о них ничего сказано, да и оптимзатор должен пройтись перебором если записях Amount<100 будет больше чем половина. Или я не прав????
Почему — прав. Только во-первых ему для этого нужно знать, сколько записей где Amount()<100 еще до начала выполнения запроса. S>А так я только за индексы.
Замечательно. А как насчет второго предиката? Какой индекс будет использоваться в случае ISecuredObject.AllowsAccess((Context.User as Employee).Manager)? Что будет ключом?
... << RSDN@Home 1.1.2 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>> Ну я думаю что оптимизатор еще не дошел "строить совсем другой алгоритм", то либо ручками либо в лоб. S>Вот приведи мне пример "ручками" S>> Хорошо пусть будет метод, но выборку с учетом индекса тоже можно делать абсолютно не вникая в тонкости. Что в общем то и делаю, но на объектном уровне. Все те же подходы. S>Как интересно. А что ты используешь в качестве ключа такого индекса? Как ты определяешь момент, когда ключ изменился?
Ну вот тебе простой пример, мне нужно сделать выборку по Amount, в навигационном объекте все данные об индексах таблицы есть и если есть индекс соответствующий данному свойству то наложить Range не проблема. А вот если такого индекса нет то вперед с песней и перебором.
Ситуация другая когда Amount вычисляет значения из связанного с данным объектом поля другого объекта при чем данный объект может быть различных типов, а может еще быть и третьим четвертым в цепочке связей. Ответ только перебором. Причем таких ситуаций не так уж и мало.
Но зато КАКАЯ Гибкость.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> А вот тесты на памяти дают 4 кратное превосходство Хэш таблиц над Б+ деревьями. M>Ну ты пойми, что в реальных системах никогда у тебя не бует такого счастья, как все в памяти.
Согласен, но сколько в реальных системах используется память???
Тот же Raid массив прежде всего выгоден за счет огромного Кэша с упреждающим чтением. И зачем нужны тогда 64 битные процессоры???
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Согласен, но сколько в реальных системах используется память???
На 100%.
Например, в загруженных блокировочниках в принципе не самая большая редкость, когда больше 40% памяти отводится только под блокировки.
S>Тот же Raid массив прежде всего выгоден за счет огромного Кэша с упреждающим чтением. S>И зачем нужны тогда 64 битные процессоры???
Кеш и массив мало связаны, и не смотря на все потуги, дотянуть производительность дисковой памяти до ОЗУ, пока даже близко не удается.
Здравствуйте, Sinclair, Вы писали:
S> В ОДБМС, напротив, полагают, что запросы типа id<5 делатья будут редко (если вообще их разрешили), а самые частые — это траверсинг, т.е. вытаскивание 1 объекта по его ID.
То есть, там тот самый .Amount()>100 в принципе не предполагается? Или я чего-то не допонял?
S> Так что в теории вроде сходится. Versant раньше использовал хеши для oid, не знаю что с ними сейчас.
Все равно, в случаях, когда напрямую в память хеш/хеши не влезают, а как правило в БД так и есть, выгоднее использовать Б-деревья даже для точечного доступа.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Все зависит от условий. Опять же я Хэш таблицу поднял только для использования группирования данных путем хранения в ней Key, Value что соответствуе клястерному инддексу. M>Бррр... Уж для группирования-то хешь зачем использовать? Какой Key-Value, и причем здесь кластерный индекс?
Пример
Select Fld1,Fld2,Fld3, Sum(Fld4),Sum(Fld5),Sum(Fld6)
From XYI
Group By Fld1,Fld2,Fld3
По сути Fld1,Fld2,Fld3 это Key
Sum(Fld4),Sum(Fld5),Sum(Fld6) это Value.
Испльзование хэш таблицы даст больший выигрыш ввиде
Хэш, Key, Value
S>> Не совсем понял M>Еще раз. B tree сортирован, хеш — нет. сортировка позволяет снизить вероятность дедлоков.
За счет блокировки диапозона ???? S>>Но поторюсь Хэш таблицы вылезли при обсуждении использовании их при группировании данных. M>Да я вообще не понимаю куда ты хеши впихнуть хочешь. Не смотря на пулеметную скорость, в БД задачах индексы на хеш таблицах использовать не выгодно. M>Это может быть выгодно, только в некоторых, довольно редких случаях, при джойнах, и это умеют делать все БД. Если оптимизатор посчитает, что для джойна выгоднее использовать хешь, то сервер его и использует, но держать постоянный хешь индекс смысла не имеет.
Ага
Select * From Doc,Tovar Where Doc.TovarID=Tovar.ID
очень редкий случай?????
Считай все, что основано на соединении по ключу.
Пример Справочник товаров в зависимости от предприятия ассортимент ограничен для кого это 1000 а для кого и 100 000. При этом использовать диапозон этих ключей представляется маловероятным.
Да и бог с ними с Хэшами. Проектировщики БД сами с усами. Но можно найти много ситуаций где выгодно их применять.
К стати по вопросу по Кубам и времени их заполнении у Вас не было перфоманса о лимитируещем звене. Или его построение велось с клиента. Уж ооочень долго.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Согласен, но сколько в реальных системах используется память??? M>На 100%. M>Например, в загруженных блокировочниках в принципе не самая большая редкость, когда больше 40% памяти отводится только под блокировки.
Во во и я о том же. Все равно как не крути память хотят пожрать все, но используется только часто используемая. Все таки интересно посмотреть когда 64 разрядную Win 2003 сделают под Athlon 64, и когда будет возможен запас по памяти. S>>Тот же Raid массив прежде всего выгоден за счет огромного Кэша с упреждающим чтением. S>>И зачем нужны тогда 64 битные процессоры??? M>Кеш и массив мало связаны, и не смотря на все потуги, дотянуть производительность дисковой памяти до ОЗУ, пока даже близко не удается.
Но всеже это уже не не напряги как раньше с диском. А насчет Кэша и массив то покупаешь память и прикручиваешь к раидам сколько купишь столько и будет кэш у каждого диска. Сам не проверял но соседи в восторге.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Испльзование хэш таблицы даст больший выигрыш ввиде S> Хэш, Key, Value
Так в этом случае еще больший выигрыш даст indexed (materialized) view, что обычно и делается.
M>>Еще раз. B tree сортирован, хеш — нет. сортировка позволяет снизить вероятность дедлоков. S> За счет блокировки диапозона ????
Нет конечно.. За счет того что разные параллельные запросы использующие один и тот же индекс, гарантировано будут перебирать записи в одном и том же порядке.
S>Select * From Doc,Tovar Where Doc.TovarID=Tovar.ID S> очень редкий случай????? S> Считай все, что основано на соединении по ключу.
Так вот по такому запросу я сразу не скажу что выгоднее хэш джоин, merge или loop.
Сильно зависит от селективности и количества записей удовлетворяющих предикату в обеих таблицах.
S> Проектировщики БД сами с усами. Но можно найти много ситуаций где выгодно их применять.
Ну так об чем и речь, что там где выгодно — они и применяются, но таких мест очень мало. И это уж ни как не прямые индексы к таблице.
К тому же еще такой момент. Ты писал, что это аналог кластерного индекса по PK, так вот кластерный индекс по PK в большинстве случаев далеко не самый оптимальный вариант.
S> К стати по вопросу по Кубам и времени их заполнении у Вас не было перфоманса о лимитируещем звене. Или его построение велось с клиента. Уж ооочень долго.
Ну вот ты опять про своего клиента. Все на одной машине, одна система делает, причем во время перестроения куба OLTP нагрузка отсуствует как класс.
Это не долго — это нормально.
S>> К стати по вопросу по Кубам и времени их заполнении у Вас не было перфоманса о лимитируещем звене. Или его построение велось с клиента. Уж ооочень долго. M>Ну вот ты опять про своего клиента. Все на одной машине, одна система делает, причем во время перестроения куба OLTP нагрузка отсуствует как класс. M>Это не долго — это нормально.
Это нормально было лет 10 назад. А 10 лет назад вычислялся наверное 70 часов????
Ненормально это. И когда зарплата начисляется около часа в монопольном режиме. Итд. Наверное я отстал от жизни.
и солнце б утром не вставало, когда бы не было меня
Re[16]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
30.01.04 18:04
Оценка:
Здравствуйте, Merle, Вы писали:
>Дело в том, что сейчас все прогрессивное человечество, в едином порыве, переползает на >64 разрядный Intel, и подобный переход довольно серьезно влияет на относительно >высокоуровневые алгоритмы. У Oracle есть нехилый опыт написания под под подобную >архитектуру на спарках, чего не скажешь про MS и даже, как говорят, про команду >разработчиков DB2 UDB (хотя по идее уж IBM'ерам-то опыта не занимать).
Аргументы по поводу проблем IBM и MS в 64-и bit???
M>Дело в том, что сейчас все прогрессивное человечество, в едином порыве, переползает на 64 разрядный Intel
хм помоему быстрее на Athlon 64 переползут.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> хм помоему быстрее на Athlon 64 переползут.
Чего-то я не видел 64 процессорных серверов на атлоне, а на итаниуме их как грязи.
Пока за Атлон серьезные производители серверов, типа HP, Unisys, ect., не возьмутся то и говорить не о чем..
Здравствуйте, Аноним, Вы писали:
А>Аргументы по поводу проблем IBM и MS в 64-и bit???
А каке нужны аргументы?
Ты хочешь сказать, что с оптимизировать систему под другую архитектуру — нефиг делать и особого опыта не нужно?
У MS с таким опытом вообще все грустно, слава богу, что 64bit сиквел себя очень не плохо показал, но этого явно недостаточно и там есть еще чег подкручивать. У IBM'еров UDB разрабатывает совершенно отдельная команда, у которой опыта работы на таких системах тоже не дофига. Но надо признать, что они молодцы, поскольку на тех же tpc-с тестах DB2 смотрится получше Оракла.
(см. 4 и 5 места Non-Clustered TPC-C by Performance)
Здравствуйте, Merle, Вы писали:
M>Чего-то я не видел 64 процессорных серверов на атлоне, а на итаниуме их как грязи. M>Пока за Атлон серьезные производители серверов, типа HP, Unisys, ect., не возьмутся то и говорить не о чем..
Да не, зря ты так. О нем от производителей больших железок очень хорошие отзывы. Sun уже даже анонсировал линейку серверов на них (кто знает, может со временем спарки и уйдут на пенсию).
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Аргументы по поводу проблем IBM и MS в 64-и bit??? M>А каке нужны аргументы? M>Ты хочешь сказать, что с оптимизировать систему под другую архитектуру — нефиг делать и особого опыта не нужно? M>У MS с таким опытом вообще все грустно, слава богу, что 64bit сиквел себя очень не плохо показал, но этого явно недостаточно и там есть еще чег подкручивать. У IBM'еров UDB разрабатывает совершенно отдельная команда, у которой опыта работы на таких системах тоже не дофига. Но надо признать, что они молодцы, поскольку на тех же tpc-с тестах DB2 смотрится получше Оракла. M>(см. 4 и 5 места Non-Clustered TPC-C by Performance)
Ну разрабатывает другая команда и что из этого DB2 LUW (Linux, UNIX, Windows)
наименее конcерванивная из всех DB2 (400,390,LUW,VSE/VM)
Сколько считается дофига заниматься разработкой 64-bit??? 5 лет недостаточно???
И опять же ты ничего не сказал про проблемы. Только про свои ощущения.
Здравствуйте, Аноним, Вы писали:
А>Сколько считается дофига заниматься разработкой 64-bit??? 5 лет недостаточно???
Они что, под 64bit все 5 лет разрабатывали? Нет конечно.
Насколько я знаю команду UDB мариновали вместе с разработчиками DB2 под майнфреймы около 2х лет, а потом отправили под обычные интелы 32бит разрабатывать, чем они и занимались.
А>И опять же ты ничего не сказал про проблемы. Только про свои ощущения.
Ну например эффективный алгоритм сканирования индексов совсем другой...
Я не являюсь экспертом в разработке низкоуровневых алгоритмов зависящих от разрядности процессора и поэтому могу всказывать только свои ощущения. О чем я собственно и написал.
Мы уже победили, просто это еще не так заметно...
Re[20]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
02.02.04 16:50
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Сколько считается дофига заниматься разработкой 64-bit??? 5 лет недостаточно??? M>Они что, под 64bit все 5 лет разрабатывали? Нет конечно. M>Насколько я знаю команду UDB мариновали вместе с разработчиками DB2 под майнфреймы около 2х лет, а потом отправили >под обычные интелы 32бит разрабатывать, чем они и занимались.
Все было не так. Команда разработчиков UDB разрабатывала DB2/VM. После того как IBM решил что основная операционка для S/390 это OS/390 они переключились на AIX + OS/2. После того как появилась IBM Software Group они начали разрабатывать под все остальное.
А>>И опять же ты ничего не сказал про проблемы. Только про свои ощущения. M>Ну например эффективный алгоритм сканирования индексов совсем другой... M>Я не являюсь экспертом в разработке низкоуровневых алгоритмов зависящих от разрядности процессора и поэтому могу >всказывать только свои ощущения. О чем я собственно и написал.
Проблемы были но они большей части касались Connectivity. 32-bit clients не могли соединятся с 64-bit и наоборот
И было не очень удобно производительность на машинах с памятью больше 8GB c 32-bitами.
Не знаю как у Oracle. A у Db2 полная совместимость между 64-bit и 32-bit базамию (Структуры данных на дисках не отличаются) Алгоритмы наверное другие. Но как ты уже заметил в одном из постов по поводу tpc-c дисков и контроллеров у DB2 было меньше.
Re[18]: Сравнение Oracle и MSSQL
От:
Аноним
Дата:
02.02.04 16:57
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Аргументы по поводу проблем IBM и MS в 64-и bit??? M>А каке нужны аргументы? M>Ты хочешь сказать, что с оптимизировать систему под другую архитектуру — нефиг делать и особого опыта не нужно? M>У MS с таким опытом вообще все грустно, слава богу, что 64bit сиквел себя очень не плохо показал, но этого явно недостаточно и там есть еще чег подкручивать. У IBM'еров UDB разрабатывает совершенно отдельная команда, у которой опыта работы на таких системах тоже не дофига. Но надо признать, что они молодцы, поскольку на тех же tpc-с тестах DB2 смотрится получше Оракла. M>(см. 4 и 5 места Non-Clustered TPC-C by Performance)
Да и вообще 64-bit'a это не панацея в два раза производительность они не увеличат.
Есть задачи где с ними быстее есть где медленее.
Одно можно сказать 64-bit'a нужно если
1) У вас больше чем 8Gb RAM
2) БД больше чем 30GB
3) Тяжелый I/O, Особенно Random I/O
4) Большие сортировки с построением индексов
Я не думаю что на Российском рынке таких приложений очень много. Хотя кто знает...
B>>VFP и PB не видел, но Дельфи и .NET ты скорее зря привел в качестве примера. B>>Формсы рулят по скорости создания надежно работающих приложений. B>>А на дельфи и .NET столько всего придется делать, чтобы оно хоть как-то зажило.
Хе хе... А ваш уважаемый Quest SQL Navigator на писан на Borland Delphi (возможно на BorlandC++ Builder кооторый от дельфи далеко не ушел), так что не надо ля-ля.
B>>p.s если понимать цели, задачи и возможности, то даже формсы рулят. A>В принципе, согласен. Но я упирал не на функциональность средств — а на их реализацию. Руки надо отрывать за такой ГУЙ.
Это точно!
B>>А у MS для MSSQL такого нет.
У MSSQL для такого есть Microsoft Visual C#/VB.NET/C++
B>>У них даже репортера своего нет, о чем тут можно разговаривать и что тут можно сравнивать вообще?-)
Это да... но уже подоспели: Microsoft SQL Report Services
A>Да черт с ним, с MSSQL — мне он пабарабану. Я начинал с того, что удивлялся — почему родные Оракловские ГУИ-средства такие кривые. Почему Quest Software может — а сам Oracle — никак.
Видимо потому что Quest пользуется Borland'овским софтом
Вот если бы они MSовским пользовались...
А то SQLNav4.exe занимает аж 13Мб, типично Borland'овский размер
Здравствуйте, slavdon, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, <Аноним>, Вы писали:
А>>>Вот только Юкона нет и еще пару лет небудет. S>>Выходит в конце 2004. Та пребета, которая есть сейчас, уже внушает уважение. S>Середина 2005 а Юкона все нет и нет....
Дык оказывается, что еще и .НЕТ и Виста не совсем "вместе"... Ай-яй-ай-яй-ай...
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Celtic Angels — Angels Sea";
(Обреченно так..)
Мы уже победили, просто это еще не так заметно...
Все, что пишет сам Oracle и при этом ЭТО имеет какой-то GUI — полное убожество 
А еще я слышал понятие "ActiveX в HTML-страницах". 
