Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 30 31 32 33 34 [35] 36 37 38 39 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
коллега ЧАЛА
Guest
DocAl

Чего-т я не понял, это "англицкий" -- язык программирования?


То есть PREPOD енто действительно по-англицки преподаватель, а UCHICA - учится. Спасибо - буду знать.
15 ноя 06, 20:24    [3406265]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
коллега ЧАЛА
Guest
softwarer

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


Не, с такими зубрами в SQL как Вы сложно сказать кого надо приглашать. Леонидыч Вас легко расколет, а мне или другому кому нужно назубок знать SQL а даже не РМД, чтобы реагировать адекватно на Ваше незнание других вопросов, которое Вы скрываете знанием SQL. Можно только порассуждать о плюсах и минусах узкой специализации но это ж уже не сравнение СУБД.
15 ноя 06, 20:32    [3406284]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
коллега ЧАЛА
Guest
Но самое удивительное, что Вы как в воду глядели. Тока не в командировку а в отпуск на недельку.
15 ноя 06, 20:39    [3406300]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
коллега ЧАЛА

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

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

коллега ЧАЛА

Они в навигаторе работают и просто получают ответы на свои запросы без программирования.

А какие пользователи программирут? Все ведь пользуются теми или другими тулсами. Да и интерфесы у иных тулсов покруче могут быть, чем у ЧАЛовского навигатора. Сам то он, судя по всему, тоже как и те пользователи никогда реально не программировал. Стал быть надыбал где-то тот навигатор, тем более их полно. У Оракла и то есть такое название в какой-то тулсе по отчетам.

коллега ЧАЛА

Какая ж ОБД без навигатора и ради чего-же делать ОСУБД если потом все равно все время программировать?

Пока не выяснили какая она с навигатором. Озвучте, плиз, название хоть одной из них, фирму производителя. Если она что-то из себя представляет, думаю, можно про нее и найти что-нить.
То что ЧАЛ рассказывал - это что-то бессвязное и смешное. Получается ООБД, но без ООП. Т.е. в ней осталось только то, что "понимает" ЧАЛ, а что ему совсем туго воспринимать, то "бесполезно для БД". Не хватило пороху на ООП, а обрезок-недоделку назвали ОСУБД. А ЧАЛ сделал вид, что это лучше. Выдавать Г за конфетку, а конфетку за Г - вот, похоже, его главная наклонность.

коллега ЧАЛА

Но продвинутее Леонидыча я когда встречу кого-нибудь тогда смогу что-то сказать.

Вы что же вообще совсем не видели никого? Ну Вы там даете стране угля. Сложнее, по моему, много труднее найти менее продвинутого, чем более продвинутого. Ваша контора ведь не та где он был года два назад? Забыл название, но у нее система была установлена на Балабановской спиченчной фабрике. Но последние (в отлчие от первых) их тексты, что я видел в инете, значительно более адекватны, чем у ЧАЛа. Они просто продвигают теперь решения на Каше, свои тулсы еще к нему приделывают для упрощения разработки. И потому я подумал, что его отодвинули.

коллега ЧАЛА

Но и не наблюдаю человека окромя Леонидыча, чьи знания хотя по косвенным признакам были достаточны.

См. выше

коллега ЧАЛА

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

А уж када врубился можно коньки отбросить от хохота.
15 ноя 06, 22:22    [3406483]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
Не знаю как у Вас в каше или М, а MS SQL делает выборку по индексу, уверен что и Оракл тоже будет - это если делать с уровня 1.
Если надо выборки с других уровней - надо делать вычисляемые поля и на них вешать индексы, а лучше вообще не извращаться, а сделать несколько полей.
Поскольку эта структура - просто эмуляция возможностей и жести (как бы сказал Gluk) каше.

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

SergSuper

Sergei Obrastsov
Клиентское приложение может раскрывать узлы поочередно, последовательными запросами с доступом по индексу

тоже самое касается и моей структуры, по моему это не менее очевидно

А я причем? Это Ваша фраза, зачем Вы мне-то на нее отвечаете?
Если это продолжение предыдущего ответа, тогда не совсем понятна квота.
И все же, да, "клиентское" и т.д., я не спорю. Речь ведь не об этом шла. А о том, что в том виде,
в каком вы его создали, индекс не обеспечивает производительности. Значит структура в виде
таблицы с двумя полями не адекватна предоставленному дереву. То, что оно туда поместилось,
не означает ничего, с таким же успехом можно было использовать таблицу с одним полем, разделив индекс и данные чем-нибудь.
15 ноя 06, 23:30    [3406611]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
Sergei Obrastsov
с таким же успехом можно было использовать таблицу с одним полем, разделив индекс и данные чем-нибудь.


Я правильно понимаю, М-системы так устроены?
15 ноя 06, 23:39    [3406633]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
мод
Sergei Obrastsov
Разработчики тоже называют его array. Но может Вам виднее?

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

Не понимаю, что Вас не устраивает. Данная конструкция позволяет ее использование в том числе
и так, как Вы привыкли.
15 ноя 06, 23:41    [3406639]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Sergei Obrastsov
В "многомерности" массивов. Это неочевидно?
я знал! я знал! я предсказывал!
Пару страниц назад этого топика предсказал, что всё же дойдём до многомерных массивов :-)

Предполагаю, что меня ждет ужасающее разочарование, я столько лет работал не с тем, с чем
думал. Ну что ж, я морально готов, жду очередного разоблачения. :)
15 ноя 06, 23:44    [3406643]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
OS/360
Sergei Obrastsov
с таким же успехом можно было использовать таблицу с одним полем, разделив индекс и данные чем-нибудь.


Я правильно понимаю, М-системы так устроены?

Вы о таблице с одним полем? Нет, неправильно.
15 ноя 06, 23:46    [3406649]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
Может Cache на VSAM похож?

http://www.redbooks.ibm.com/redbooks/SG246105/wwhelp/wwhimpl/js/html/wwhelp.htm
15 ноя 06, 23:54    [3406675]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
коллега ЧАЛА

Не могу с Вами согласиться, хотя Вы вроде и больше меня знаете РСУБД. Но Вы уходите от тривиального примера. Представление в ОСУБД двух объектов и связи М:М между ними
Преподаватель<-- Учит/Учится у--> Студент
и после описания схемы БД пользователи могут работать - вводить данные делать запросы, отчеты без программистов и программирования.
У Вас вроде в РСУБД а не в какой-то дополнительной среде получается
PREPOD
STUDENT
UCHICA
(или чисто англицкими словами назовете свои таблицы) и пользователи с этим не смогут работать окромя продвинутых аналитиков выучивших языки программирования.


create table person
(id number primary key, 
 first_name varchar2(4000), 
 last_name varchar2(4000)
)
;

create table teaches 
(teacher_id number, 
 student_id number,
 constraint pk_teaches primary key (teacher_id, student_id)
)
organization index
;

create view who_teaches_whom as
select t.first_name as teacher_first_name, 
         t.last_name as teacher_last_name, 
         'teaches' as does_what,
         s.first_name as student_first_name, 
         s.last_name as student_last_name
 from person s,
        person t,
        teaches tc
where s.id=tc.student_id
   and t.id=tc.teacher_id
;
Дальше с помощью продукта типа Oracle Discoverer аналитик (умеющий правда обращаться с Excel - обычно они это умеют), получает доступ к этой информации без написания столь нелюбимого вами SQL вообще. Ни одной строчки кода писать не надо - только мышом щелкать. Кстати большинство аналитиков хорошо знают мат. статистику поэтому изучение SQL не представляет для них никакой проблемы. Как правило, когда их учат статистике то лабораторные работы у них на SAS и SQL.

коллега ЧАЛА

Вроде бы все просто. Но Вы говорите про ADABAS - да я плохо знаком, и это плохо, но и Вы почему-то не используете ADABAS. Про Хомского говорите - да, не знаком, и Леонидыч мне говорил, что плохо это и могут засмеять. Да моло ли отчего могут засмеять.
Пока я Вам искренне сочувствую, даже больше чем себе. Сочувсвовать Леонидычу несерьезно.

Почитайте учебник по мат. лингвистике - вам все станет понятно с обработкой запросов на естественном языке. Мне надоело спорить о численных методах решения дифференциальных уравнений с персонажами которые не знают что такое производная.
16 ноя 06, 00:28    [3406746]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
OS/360
Может Cache на VSAM похож?

http://www.redbooks.ibm.com/redbooks/SG246105/wwhelp/wwhimpl/js/html/wwhelp.htm

Нет, совсем не похож.
16 ноя 06, 01:10    [3406794]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
jekaSQL
Member

Откуда: Бабруйск
Сообщений: 596
Читал я про задачи и деревья и понял, толи вы разговариваете на каком-то релятивстскоматематическом уровне, толи одно из двух.

Предлагаю рассмотреть пару задач.
1. Просто список данных и поиск по нему. Например, список натуральных чисел и их названий.
Делается так. создаем табличку:

create table nums (num int, name varchar(100))

заполняем:
insert into nums(num, name) values(1, 'One')
insert into nums(num, name) values(2, 'Two')
insert into nums(num, name) values(3, 'Три')
insert into nums(num, name) values(4, 'Дважда два')
...
insert into nums(num) values(10000000, 'Dofiga')
ищем, например вокализацию числа 234523

select * from nums where num = 234523
получаем:
234523, 'двести тридцать четыре тыщщи с копейками'

сервер выполняет полный скан таблицы и находит нужное число за примерно попыток - кол-во записей/2, это так потому, что записи хранятся в беспорядке и читаются в память тоже в беспорядке. Пока их не упорядочили.
Поскольку так искать порой(но невсегда!) невыгодно, то можно создать индекс по полю. Вот так:

create index nums_idx_for_sql_ru on nums(num)

С этого момента в БД создаётся новая сущность, которая представляет собой сбалансированное дерево значений поля num.
Теперь запрос
select * from nums where num = 234523

выполняется за ln(кол-во записей) попыток. Ну если моя математика меня не подводит. Что понятно быстрее. Иногда. Как можно заметить, в запросе нет никакого указания на использование индекса. Оптимизатор решает это сам. Вообще всю нагрузку на создание и актуализацию индекса сервер берет на себя. Для программиста его использование прозрачно.
Конечно, имеется возможность сопровождать индексы вручную и явно заставлять сервер использовать их в запросах. Это на тот случай, когда программист лучше сервера знает конкретные особенности используемых данных и приложения. Это называется хинты, их тут уже упоминали. Но можно этого не делать и, как правило, лучше этого действительно не делать. Достаточно грамотно создать индексы.

2. Теперь про деревья, в понятиях логики приложения, а не его физической реализации.
Вот структура, скажем, Земли:

create table orgstructure (id int, parent_id int, name varchar(100))

где, как несложно догадаться, parent_id - это id родительского элемента.
Данные:
insert into orgstructure (id, parent_id, name) values (1,0,'God')
insert into orgstructure (id, parent_id, name) values (2,1,'Putin')
insert into orgstructure (id, parent_id, name) values (3,1,'Bush')
insert into orgstructure (id, parent_id, name) values (4,2,'ГосДума')
insert into orgstructure (id, parent_id, name) values (5,2,'Олигархи')
insert into orgstructure (id, parent_id, name) values (6,5,'Dorogie rossiyane')
insert into orgstructure (id, parent_id, name) values (7,2,'Mcdonalds')
и так далее.
Выборка из дерева проста и незамысловата:
Нужен родитель известной записи :
select * from orgstructure where id = известный нам parent_id
Нужны дети:
select * from orgstructure where parent_id = известный нам id
Нужны все братья/сестры:
select * from orgstructure where parent_id = известный нам parent_id
Тут мои неглубокие знания оракла :) очень неглубокие...
Нужны все предки:
select * from orgstructure start with id = известный нам id connect by parent_id = prior id
Нужны все потомки:
select * from orgstructure start with id = известный нам id connect by id = prior parent_id
Два последних случая в MSSQL правда не прокатывают(пока?).

По полям id, parent_id можно построить индекс, такой же, как в п.1 и всё ускорится.

В отдельных случаях, особенно в MSSQL, не имеющем такой фишки, как start with... connect by... можно построить уже ручками программиста отдельную табличку типа:

create table orgstrtree(parent int, child int, level int)

где в parent хранить id всех записей, имеющих потомков, в child хранить id соответствующих потомков(причем не только детей, а внуков, правнуков и т.д.), а в level уровень в иерархии.
Соответственно выборка всех, скажем, предков, отсортированная от старших к младшим будет такова(тут уже MSSQL):
select * from orgstree ot inner join orgstructure o on ot.parent = o.id where ot.child = известный нам id order by level
Поддержание такой таблички уже конкретно требует от программиста: либо создавать триггеры, либо создавать строгую политику разработки и сопровождения и т.п. Вот это уже имхо смахивает на ручное создание деревьев. Но такое требуется редко и нечасто.

Надеюсь я просветил немного тему, а то совсем грустно.
Прочитать про использованные операторы и конструкции можно в любом хелпе по MSSQL, скажем www.msdn.com. Там всё крайне просто и доступно.
16 ноя 06, 01:27    [3406807]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
коллега ЧАЛА
Дейту я доверяю, но это ж опять под влиянием Леонидыча, может напрасно.

Видать плохо усвоили уроки Учителя. Если бы усвоили хорошо, то Дейту бы как раз не доверяли, поскольку ЧАЛ неоднократно доказал, что у Дейта полно противоречий и ошибок, начиная с самой главной: Дейт считает РМД полезной, а ЧАЛ доказал, что РМД абсолютно бесполезна.
16 ноя 06, 02:03    [3406821]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Sergei Obrastsov
OS/360
Может Cache на VSAM похож?

http://www.redbooks.ibm.com/redbooks/SG246105/wwhelp/wwhimpl/js/html/wwhelp.htm

Нет, совсем не похож.


Скорее на "IMS для бедных", со сломанным IMS/TM и вообще кастрированный.
16 ноя 06, 02:30    [3406834]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Gluk (Kazan)
Sergei Obrastsov
В результате вместо выборки, скажем, 1000 записей, сканируются
все.


Как попросишь, столько и отсканирует. Кстати, если эта 1000 равномерно размазана по таблице, Full Scan может быть эффективнее доступа по индексу


неужели?

количество просмотренных блоков при fullscan = n а для сбалансированного дерева = log_k(n)

Чувствуете разницу?

FULLSCAN никогда не буде быстрее поиска по дереву. Попытаетесь доказать обратное?
16 ноя 06, 07:12    [3406934]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
мод
Sergei Obrastsov
Локальные массивы в M абсолютно такие же.

Это не массивы. Называйте вещи своими именами:
массив, последовательный файл, индексно-последовательный файл, список и т.д - это все разные типы данных, а вас имхо путаница.



может потрудитесь дать формальные определения этих терминов и все успокоятся? Желательно со ссылками на автора определения
16 ноя 06, 07:16    [3406941]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
OS/360
Sergei Obrastsov
с таким же успехом можно было использовать таблицу с одним полем, разделив индекс и данные чем-нибудь.


Я правильно понимаю, М-системы так устроены?


Что значит "так"? Для того чтобы понять как они устроены нужно прочесть более чем только один топик на sql.ru и как минимум пощупать это руками
16 ноя 06, 07:23    [3406947]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SeaGate
Member

Откуда: Новосибирск
Сообщений: 1728
Rus000

количество просмотренных блоков при fullscan = n а для сбалансированного дерева = log_k(n)

Чувствуете разницу?

FULLSCAN никогда не буде быстрее поиска по дереву. Попытаетесь доказать обратное?

Не понял, не знаете случаев, когда полное сканирование таблицы будет быстрее доступа по индексу?
16 ноя 06, 07:30    [3406958]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov

Это действительно очевидно. Как и то, что выборка элементов 2-го и последующих уровней,
без задания 1-го, пойдет как Full Scan. Я не слишком самоуверен? :)


Слишком. 2 уровень НИЧЕМ не отличается от первого. Если в первом не было FullScan с какого перепуга он будет во втором ???
16 ноя 06, 09:57    [3407320]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Sergei Obrastsov
Не понимаю, что Вас не устраивает.

Меня не устраивает, когда путают типы данных, физическую и логическую структуры, модель данных и метод доступа ну и т.д. (вообщем матчасть)
16 ноя 06, 09:58    [3407328]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
коллега ЧАЛА
Но самое удивительное, что Вы как в воду глядели. Тока не в командировку а в отпуск на недельку.


цЫрк с конЯми
16 ноя 06, 09:59    [3407330]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
OS/360
Может Cache на VSAM похож?

Нет, скорее на ISAM (имхо).
16 ноя 06, 10:04    [3407360]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
FULLSCAN никогда не буде быстрее поиска по дереву. Попытаетесь доказать обратное?


Вот тут Вы не правы. Поиск по индексу - дополнительные издержки и существует масса случаев когда эти издержки не окупаются. Например когда табличка помещается в одном блоке. Или когда из таблички нужны ВСЕ данные. Будете спорить ?
16 ноя 06, 10:05    [3407367]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
RENaissance
Member

Откуда: Муром->Москва
Сообщений: 10895

Gluk (Kazan)
+1
З.Ы Добавлю, что FULL SCAN будет легче по затратам и быстрее, если индекс, по которому идет отбор, яляется монотонным.


Posted via ActualForum NNTP Server 1.3

16 ноя 06, 10:10    [3407405]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 30 31 32 33 34 [35] 36 37 38 39 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить