Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 pavelp

>Осень. Обострение.

Вспомнилась классификация F.W. от Mike Reed, прямо про ЧАЛ-а нашего - http://redwing.hutman.net/%7Emreed/warriorshtm/loopy.htm

На русском тут - http://sigin.dephine.org/2005/05/25/voiny_interneta--psix/
30 окт 06, 23:05    [3332582]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Прошу прощения, тут я по-видимому ошибся
create table P ( //список студентов у каждого преподавателя
 teacher teacher_t,
 student student_t,
 primary key student
 );
create table S ( //список преподавателей для каждого студента
 student student_t 
 teacher teacher_t,
 primary key teacher
 );
Должно быть просто дублирование таблиц, в обоих случаях primary key (teacher,student). Теперь непонятно зачем Sergei Obrastsov ввел два одинаковых массива
P(преподаватель,студент)=
S(студент,преподаватель)=
Или они все-таки не одинаковые? Порядок (студент,преподаватель) или (преподаватель,студент) играет роль?

LittleCat

Вот с этого места можно поподробне ? Как будет выглядеть вставка записи "Иванов учится у Петрова" ?

insert into PS (p,s) values (petrov_id,ivanov_id);
commit;
или так, если teacher и student это фамилии и они уникальны:
insert into PS (p,s) (select P.id,S.id from P,S where teacher='Петров' and student='Иванов');
commit;


kvasov
c127
Приведите пример, что за проблема, устали уже ждать сногосшибательного примера, который вобъет последний гвоздь в гроб РСУБД. Все обещают-обещают и ничего не приводят.


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

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

повторяю, не считаю себя специалистом, мне по барабану и SQL и М, но вот на РСУБД можно такое сделать?

на М это вроде делается с пол-пинка
(хотя я не делал :-)

Если совсем РСУБД решение, то например так
create trigger xx after insert on temperature_table 
  referencing new as n
  for each row
  when (n.t>T)
  begin
  //шлем сообщение
  end;

kvasov

сегодня вроде как модно говорить про интернет

С чем соединить РСУБД?
- с "платформой Net"
- с "JavaRunTime machin"
- с PHP

а М не нужны эти чужие технологии вообще, М может выдать html-ответ в любой открытый ею порт.

РСУБД тоже в общем-то не нужны эти технологии, ASCRUS выкладывал пример веб сервера на сайбейз АСА. Но кому это нужно, ведь у нас нет задачи минимизировать количество используемых продуктов, наша задача минимизировать расходы на разработку ПО. А это в основном есть расходы на оплату труда программиста и иногда стоимость стороннего ПО. Поэтому обсуждать "как все сделать только средствами РСУБД" не имеет смысла, имеет смысл обсуждать "как все сделать меньшими усилиями и подешевле".

Rus000

Гм ... а что мешает нам сделать так

Наверное ничто не мешает, я предложил аналог кода, приведенного Sergei Obrastsov.

LittleCat
softwarer
Итого, получим, что kdv оказался пессимистичен в обоих случаях.

Скорее, он оказался оптимистичен, поскольку именно так и высказался
никак. ни в SQL ни в M одной операцией это не делается.
Но это уже терминологический спор, насчет отличий пессимистов и оптимистов :-)

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

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

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

dmitryn

Самим собой напрашивается решение создать платформу включающую в себя СУБД и полноценное средство создания приложений.Парни из интерсистемс додумались до этого. ПОЧЕМУ НИ ОРАКЛ НИ МЕЛКОСОФТ до этого не дошли????.

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

Сервер должен заниматься серверными задачами, а клиентское приложение - клиентскими, смешивать их себе дороже.
30 окт 06, 23:06    [3332584]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
kdv
RUS000
^S(sid)=студент
^P(pid)=преподаватель
^PS(pid,sid)=""
^SP(sid,pid)=""


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

Соответствующим - да, единственно правильным - нет. Удобным - тоже нет.
Как будем преподавателя искать? Полным перебором?

kdv

И кстати, примерно в такую же структуру (если не чуть страшнее) превратит попытка создать РСУБД-аналог таблиц в Cache.

Вообще-то это он и есть. В смысле "аналог" следующей структуры (только
^SP лишний, поскольку в SQL структуре key(s.id,p.id) отсутствует):
create table P ( 
 id int default autoincrement not null primary key,
 teacher teacher_t,
 );
create table S ( 
 id int default autoincrement not null primary key,
 student student_t,
 );
create table PS ( 
 p int references p.id,
 s int references s.id,
 primary key(p,s)
 );
31 окт 06, 01:05    [3332812]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
c127

наша задача минимизировать расходы на разработку ПО.


Понял, понял.

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

(К сожалению, самого Cache пока нет - кто ж знал, что он такой эксклюзивный, подстава конкретная)

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

а вот это,

begin
// шлем сообщение - прочитать температуру
end

begin
// шлем сообщение - включить вентилятор
end

мне понравилось :-)
31 окт 06, 01:07    [3332819]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
Теперь непонятно зачем Sergei Obrastsov ввел два одинаковых массива
P(преподаватель,студент)=
S(студент,преподаватель)=
Или они все-таки не одинаковые? Порядок (студент,преподаватель) или (преподаватель,студент) играет роль?

Они, естественно, не одинаковые. Порядок играет роль.

c127

LittleCat
softwarer
Итого, получим, что kdv оказался пессимистичен в обоих случаях.

Скорее, он оказался оптимистичен, поскольку именно так и высказался
никак. ни в SQL ни в M одной операцией это не делается.
Но это уже терминологический спор, насчет отличий пессимистов и оптимистов :-)

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

Вы это серьезно насчет забыть? Ну тогда и в SQL никто не застрахован.

c127

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

Ну и у нас требуется тоже только одна операция. Вы процедуру напишете?
Так и мы так же делаем. Уж наверно каждому программисту при работе на
большой задаче не дается в руки прямая запись в БД.

c127

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

^P("name",преподаватель)=pid
^P("id",pid)=преподаватель
^P("id",pid,sid)=
^S("name",студент)=sid
^S("id",sid)=студент
^S("id",sid,pid)=
Ну вот вам непротиворечивая структура. Нормализованная, ага. И симметричная, так?
В смысле, что pid-><-преподаватель и sid-><-студент
без полного перебора массивов. Ну и pid->sid, sid->pid, конечно. Чего 3-уровневая? Ну а почему нет? Так логичнее, да и плодить лишние массивы
не хочется.
31 окт 06, 01:38    [3332864]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
Приведите пример, что за проблема, устали уже ждать сногосшибательного примера, который вобъет последний гвоздь в гроб РСУБД. Все обещают-обещают и ничего не приводят. Только не просите отпарсить строку, это задача не для СУБД, подходящим средством все равно решится лучше чем на М, при необходимости я его использую и все равно выиграю в усилиях по сравнению с М.

Вот только, пожалуйста, не надо этого дешевого пафоса "последний гвоздь
в гроб"
и т.д. Парсинг строки, это, естественно, не показатель,
но достаточно симптоматично. Прочитали, передали, забрали... тоже,
конечно, время. Впрочем, этот вопрос настоящих программистов не волнует, правда? Они ведь все-равно выигрывают. Особенно на "толстом" SUN против notebook'а.

Как я уже говорил, я использую M для задач, требующих компактного
хранения данных с обеспечением быстрого доступа к ним (давний разговор об этом смотреть здесь,
сейчас в базе 118+ млн. записей с 8-кратным индексированием и счетчиками.
все это хозяйство весит 24 Гб),
или работающих напрямую с устройствами: скажем, работа со
станцией в режиме "немедленного расчета". Я уже не буду говорить об использовании M в качестве связующего фактора между разными приложениями. И тем более об удачном примении его для неординарных
задач, вроде мат.анализа и прочей лабуды.
31 окт 06, 03:24    [3332916]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127
В нормализованной схеме требуется одна операция вставки, если преподаватели и студенты уже внесены, а так обычно и бывает, но это не очень важно. Аналогичного противоречивого состояния не бывает.

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


приведенные примеры структуры также нормализованы, и все что Вы говорите для sql-решения справедливо и для этих структур.

Насчет противоречивого состояния БД.
Я правильно понял что этим противопоставлением Вы утверждаете, что структуру данных в РСУБД невозможно привести в противоречивое состояние никаким способом ... например по причине кривости рук или забывчивости разработчика?
31 окт 06, 07:06    [3333005]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Sergei Obrastsov
kdv
RUS000
^S(sid)=студент
^P(pid)=преподаватель
^PS(pid,sid)=""
^SP(sid,pid)=""


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

Соответствующим - да, единственно правильным - нет. Удобным - тоже нет.
Как будем преподавателя искать? Полным перебором?


чем Вас не устраивают взаимно инверсные ^PS и ^SP ?
31 окт 06, 07:09    [3333006]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Rus000
чем Вас не устраивают взаимно инверсные ^PS и ^SP ?

Толку-то? Найдите "Иванова" в этой структуре без полного скана. :)
31 окт 06, 07:16    [3333011]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
dmitryn
есть области где Cache является наилучшим решением.

???
dmitryn
если вам необходимо обрабатывать огромное количетство транзакций в режиме реально времени.

Это не проблема СУБД.
dmitryn

А вообще ИМХО, основное преимущество Cache заключается в том что это не просто СУБД, а платформа для разработки приложений.

Любая СУБД это платформа для разработки приложений. Progress 4GL и Informix 4GL более интегрированы, чем Cache.
31 окт 06, 11:29    [3334285]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Я
Guest
«Потребовалось всего 15 минут, чтобы организовать долговеренное хранение объектов Java в Caché. Если бы я попробовал отобразить их в реляционной базе данных, это бы заняло месяцы»
— Айран Хатчинсон, Системный Архитектор IBM

отсюда взято

АБАЛДЕТЬ! IBM использует Cache? И даже не посоветовавшись на этом форуме? И даже довольны своим выбором...
31 окт 06, 11:42    [3334429]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Я
Guest
О-хо-хо... приснилось им что ли???

"Имея всю информацию по поддержке клиентов в Caché, IBM сможет значительно проще анализировать эту инофрмацию, создавать отчеты, и принимать решения по действиям для поддержки. Айран Хатчинсон: «Caché уникален тем, что даёт возможность SQL запрашивать объектно-ориентированную информацию без ее отображения в реляционные структуры и это очень быстро. Я не мог добиться той же производительности от реляционной базы данных, и я знаю, что Caché сэкономил мне месяцы работы. Благодаря технологии, скорости, простоте использования Caché – единственный разумный выбор, который мог быть сделан».
"
31 окт 06, 11:45    [3334452]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
автор
Самим собой напрашивается решение создать платформу включающую в себя СУБД и полноценное средство создания приложений.


softwarer ответил абсолютно правильно - "целостные" решения уже никому не нужны. Если ты в него влез - то ты погиб. Сейчас уже из чистого эгоизма нельзя позволять себе изучать систему, из которой ты НИЧЕГО не сможешь применить при разработке похожего приложения другими средствами.

Теперь вернемся к преподавателям и студентам. :-)
М-цы твердят свое, SQL-цы их не понимают, и наоборот.

Почему я указал решение с 4-мя глобалами как единственно правильное:
потому что там есть ^sp(s, p) и ^ps(p, s). Дело в том, что в из ^sp нельзя получить преподавателя и тех кого он обучает, кроме как полным перебором.
Для РСУБД с точки зрения структуры в таблице связи м-м (1-м + м-1) студентов и преподавателей порядок столбцов не важен. И для запросов - неважен. Но для оптимизатора важно то, как построен первичный ключ. Если он построен по s+p то соответственно так же как в М в РСУБД нельзя найти студентов преподавателя без полного перебора таблицы. Но можно построить индекс по p+s (или хотя бы по p).
В этом случае "дублирование" получается одинаковым как для М так и для РСУБД.
Но все же, в М случаи "дублирования" данных чаще, чем в РСУБД. РСУБД не оперирует понятием "индекс" на уровне SQL. Ее это не интересует. Это задача оптимизатора.

То есть. С точки зрения модели данных: в РСУБД - 3 таблицы с индексами по ПК, в М - 3 глобала. С точки зрения производительности при поиске со всех сторон - в РСУБД 3 таблицы + доп. индекс, в М - 4 глобала.

Поборники М упирают на "производительность", т.к. для них это основное направление мозговой деятельности. Поборники РСУБД - на модель данных. Отсюда и взаимонепонимание.
Но - если индекс в РСУБД является просто дополнительной "фишкой" которую можно делать, а можно не делать, то в М такой "дополнительный индекс" - обязательная часть структуры для решения задачи.
31 окт 06, 12:08    [3334685]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
kdv
softwarer ответил абсолютно правильно - "целостные" решения уже никому не нужны. Если ты в него влез - то ты погиб. Сейчас уже из чистого эгоизма нельзя позволять себе изучать систему, из которой ты НИЧЕГО не сможешь применить при разработке похожего приложения другими средствами.

Ооочень спорное утверждение. Неужели при переходе к другим средствам вам нечего взять из предидущей системы (а архитектура ?). Неужели перекодировка это так уж сложно ?
ps. Пример (хотя и не доказательство) - OEBS, Бисквит, все продукты на 4GL
31 окт 06, 12:42    [3334957]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
kdv
Для РСУБД с точки зрения структуры в таблице связи м-м (1-м + м-1) студентов и преподавателей порядок столбцов не важен. И для запросов - неважен. Но для оптимизатора важно то, как построен первичный ключ. Если он построен по s+p то соответственно так же как в М в РСУБД нельзя найти студентов преподавателя без полного перебора таблицы. Но можно построить индекс по p+s (или хотя бы по p).
В этом случае "дублирование" получается одинаковым как для М так и для РСУБД.

Мне всё-таки кажется что есть большая разница между тем чтобы декларативно объявить о создании индекса и забыть об этом, и вставкой одинаковых данных поочерёдно в две сущности во всех местах кода
31 окт 06, 12:57    [3335072]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
dmitryn
Guest
мод
dmitryn
есть области где Cache является наилучшим решением.

???
dmitryn
если вам необходимо обрабатывать огромное количетство транзакций в режиме реально времени.

Это не проблема СУБД.
dmitryn

А вообще ИМХО, основное преимущество Cache заключается в том что это не просто СУБД, а платформа для разработки приложений.

Любая СУБД это платформа для разработки приложений. Progress 4GL и Informix 4GL более интегрированы, чем Cache.

Да не проблема для СУБД - проблема с поиском подходящего железа :)
Посмотрите назад лет на 10 - за это время в плане производительности компьютерная техника ушла далеко вперед, только вот производительность эту с вихвой съедает программное обеспечение. Так что толку от этого никакого.
Я не знаком с вышеперечисленными системами, может оно и так.
31 окт 06, 13:12    [3335174]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
dmitryn
Guest
softwarer
dmitryn
А вообще ИМХО, основное преимущество Cache заключается в том что это не просто СУБД, а платформа для разработки приложений.

Признаться, именно эта фраза в значительной степени ставит крест на желании глубоко разбираться. Автоматом решение переходит в разряд Access-подобных.

dmitryn
Самим собой напрашивается решение создать платформу включающую в себя СУБД и полноценное средство создания приложений.

Смотря кому напрашивается.

dmitryn
Парни из интерсистемс додумались до этого. ПОЧЕМУ НИ ОРАКЛ НИ МЕЛКОСОФТ до этого не дошли????.

Может быть, ты просто об этом не знаешь? За Микрософт не скажу, а Oracle уже давно поддерживает Portal и HTML DB, позиционируемые как "полноценные средства создания веб-приложений".

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

dmitryn
В результате имеем возможность разрабатывать клиент-серверные приложения в одном месте, в одной среде.

Это идея еще Oracle Forms и того же Access, либо совсем старых решений, например Clarion. Ни одному из них особого успеха она не принесла.

dmitryn
Главное - это попытка создать нечто целостное,

Между тем как профессионалы во все века испытывали потребность ровно в противоположном - в модульности, в хорошо и эффективно интегрируемых кубиках.

А что вас так смутила эта фраза? Я не говорю о том какой это супер-пупер продукт, наоборот есть масса недоработок. А вообще зря вы так, в основе Cache лежит пускай не самое лучшее ядро БД семейства М, но все-таки весьма неплохое. Были бы у разработчика такие возможности как у Microsoft, Oracle, Sun - глядишь была бы революция в ИТ, как некогда JAVA. А так Oracle, несомненно отличная база, но все ее преимущества тают когда начинают стоить такие системы как я уже говорил выше.
Да сейчас в веб проблема с GUI, но недолог тот час когда будем клепать приложения в вебе как в дельфях.
Модульность это хорошо - только вот за счет чего? За счет вот таких стеков протоколов и технологий? В проекте на котором я сейчас занят, используют технологии IBM Websphere, Portal, + Oracle, создаем корпоративные порталы. Смех сквозь слезы когда смотрю на результаты нагрузочного тестирования и требования к железу. Добавь в cache портальную технологию - цены бы ей не было для таких систем.
Насчет Portal и HTML DB - и как? Удобно, эффективно, быстро? Ваше мнение?
31 окт 06, 13:28    [3335286]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Sergei Obrastsov
Rus000
чем Вас не устраивают взаимно инверсные ^PS и ^SP ?

Толку-то? Найдите "Иванова" в этой структуре без полного скана. :)


в данном примере это было не столь неважно. Важно было показать нормализованную, эквивалентную структуру. А доп.индексы естественно можно наворачивать сколько угодно
31 окт 06, 14:32    [3335779]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
dmitryn

Да сейчас в веб проблема с GUI, но недолог тот час когда будем клепать приложения в вебе как в дельфях.


самый лучший GUI в вебе
http://www.ya.ru/

это шедевр
31 окт 06, 15:05    [3336032]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
SergSuper
kdv
Для РСУБД с точки зрения структуры в таблице связи м-м (1-м + м-1) студентов и преподавателей порядок столбцов не важен. И для запросов - неважен. Но для оптимизатора важно то, как построен первичный ключ. Если он построен по s+p то соответственно так же как в М в РСУБД нельзя найти студентов преподавателя без полного перебора таблицы. Но можно построить индекс по p+s (или хотя бы по p).
В этом случае "дублирование" получается одинаковым как для М так и для РСУБД.

Мне всё-таки кажется что есть большая разница между тем чтобы декларативно объявить о создании индекса и забыть об этом, и вставкой одинаковых данных поочерёдно в две сущности во всех местах кода


ничего не мешает определить user-defined функции вставки, апдейта, удаления и пользоваться в коде именно ими. Предварительной работы больше чуть, а гибкости в оптимизации индексов существенно выше
31 окт 06, 15:09    [3336069]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
kdv
В этом случае "дублирование" получается одинаковым как для М так и для РСУБД.
Но все же, в М случаи "дублирования" данных чаще, чем в РСУБД. РСУБД не оперирует понятием "индекс" на уровне SQL. Ее это не интересует. Это задача оптимизатора.


все правильно говорите в целом. Различие в обсуждаемы подходах в том и состоит, что для одних индекс есть фишка СУБД, которую можно даже выкинуть из рассмотрения (однако вторичные индексы объективно есть в виде хранимой сущности), а для других структура индекса и структура данных суть одно и то же, за исключением порядка группировки полей в "первичном" ключе (key) на каждом уровне дерева.

Данные, представимые в виде отношений, представимы и в виде деревьев, равно как и обратное. О чем спор? О том поддерживать ли доп. индексы? Или о том кому их поддерживать? Имхо спор только о последнем.

Давеча тут делал на M специальный вид индекса для поиска любой перестановки слов в названии организаций. Это когда хочется найти организацию зная лишь примерно как она назвается введя любое подмножество слов из названия в любом порядке. Сделал. Добавил в соотв. функциях INSERT,UPDATE,DELETE к множеству уже имеющихся на тот момент индексов и забыл об их поддержке. Результат который я получил - мгновенно работающий поиск организаций. К чему я это?
А вот мне любопытно возможно ли создать подобное стандартными средствами поддержки индексов в РСУБД? Если это не так, то это значит РСУБД разработчик будет выгужден проектировать этот индекс как сущность и строить бизнес логику приложения ориентированную на работу с этой структурой, и будет вынужден поддерживать ее целостность и непротиворечивость.
Я не сомневаюсь что это безусловно возможно, но согласитесь нарушает идеальность подхода когда данные отдельно а индексы отдельно.

Любопытно было бы увидеть реализацию для построения и поддержки в РСУБД поисковой структуры о которой я упомянул выше
31 окт 06, 15:35    [3336281]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
Rus000
А вот мне любопытно возможно ли создать подобное стандартными средствами поддержки индексов в РСУБД?

Да запросто.

SQL> select owner, object_name from dba_objects where object_type = 'INDEXTYPE' ;

OWNER           OBJECT_NAME
--------------- ---------------
CTXSYS          CONTEXT
CTXSYS          CTXCAT
CTXSYS          CTXRULE
CTXSYS          CTXXPATH
XDB             XDBHI_IDXTYP
XDB             XMLINDEX
MDSYS           SPATIAL_INDEX
MDSYS           RTREE_INDEX

Мораль: только в стандартной поставке user-defined индексов больше, чем "родных".
31 окт 06, 16:41    [3336943]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer, для кашиста это примерно как обычному человеку показать запись на М
до меня, например, не сразу дошло
31 окт 06, 16:48    [3337009]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
SergSuper
softwarer, для кашиста это примерно как обычному человеку показать запись на М до меня, например, не сразу дошло

Я же стараюсь понять приведенные здесь строки на Cache :)

Согласен, поиск общего языка здесь немаловажен. Если скажете, как лучше было изложить эту информацию, приму к сведению.
31 окт 06, 17:48    [3337514]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
dmitryn
А что вас так смутила эта фраза?

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

Я пытаюсь объяснить, чем эта фраза "антирекламна" для меня.

dmitryn
Были бы у разработчика такие возможности как у Microsoft, Oracle, Sun

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

dmitryn
А так Oracle, несомненно отличная база, но все ее преимущества тают когда начинают стоить такие системы как я уже говорил выше.

Хм. Задачу прямого доступа к оборудованию [я правильно помню?], думаю, Oracle никогда не собирался и вряд ли соберется решать. И я, если честно, совершенно не понимаю, нафига оно такое нужно. Доступ к оборудованию я предпочитаю писать, например, на ассемблере.

Само собой, у Oracle хватает слабостей, и хватает задач, для которых его не стоит применять. Как и у любого другого софта. И, кстати, это тоже аргумент, который ставит жирный крест на идее интегрированных решений - получается, что вместо неудачного компонента надо выбрасывать все целиком (либо терпеть этот неудачный компонент).

dmitryn
Насчет Portal и HTML DB - и как? Удобно, эффективно, быстро? Ваше мнение?

Представления не имею. Как я уже говорил, веб-технологии с моей точки зрения - нечто вроде песочницы с куличиками, лезть туда мне уже.. неинтересно.
31 окт 06, 17:59    [3337587]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить