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

Откуда:
Сообщений: 673
ну я
Лично я нигде в каше не видел четкой декларации какие именно глобалы в какой очередности блокируются при каких операциях sql и объектов.
Вообще у них дока не ахти...
17 ноя 06, 15:55    [3416368]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
То есть в м-системах в принципе можно реализовать и битмапные индексы, и многие другие оракловые фичи, только для этого их надо сначала самому "ручками" написать? Я правильно понимаю? Тогда хочется послушать как мы будем "ручками" писать такую монументальную фичу как поддержка ACID-транзакций.
17 ноя 06, 20:20    [3418028]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
МУМПСистам не нужно ACID, они "правильно работают с глобалами"
17 ноя 06, 20:23    [3418045]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
DocAl
МУМПСистам не нужно ACID, они "правильно работают с глобалами"


Тада вопросов больше нет. Разве что посоветовать почитать по данной теме на выбор:
1. Джима Грея
2. Бернштейна
3. Вейкума и Воссена

А потом продолжить топик.
17 ноя 06, 20:29    [3418059]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
ну я
Gluk (Kazan)
как в Cache реализуется ACID ?


consistency - это пишет программист, каше только исполняет программу
isolation - блокировки, пишет программист, каше только синхронизирует выполнение процессов

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

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

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


Глобальная проблема MUMPS в том, что его "выразительная" мощность ниже, чем у SQL. Одна строчка SQL может трансформироваться в десятки строк кода MUMPS, если начать делать как в реальной жизни - с блокировками, транзакциями, уровнями изоляции.
Для любителей почитать на английском рекомендую сайт http://www.paulgraham.com, особенно его размышления о том, что современные языки программирования движутся от Fortran к Lisp и почему. Его рассуждения вполне применимы к ситуации MUMPS - SQL.
17 ноя 06, 22:03    [3418250]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Прошу прощения за поздний ответ, провайдер завалил инет на всю ночь.

pavelvp
Sergei Obrastsov
Нет, не понимаю. Видимо, это новое веяние в РБД - использовать объединенный индекс, чтобы не заморачиваться на отдельные. Впрочем, Full Scan рулит, конечно.
Т.е. просто ответить на вопрос никак нельзя...
Попытка номер три. Как это сделает М-система?

Очередной ответ - созданием нужного индекса конечно. По-моему, это очевидно. Более
того, в предложенной структуре он есть. Но простое переливание в "таблицу с двумя полями"
съедает его преимущество. Пожалуйста, используйте свое любимое
select @date+"/"+"pb"+@v4+"/"+@v3+"/"+@idx, "Вася"
оно, конечно, будет работать, только не удивляйтесь потере производительности.
17 ноя 06, 22:35    [3418315]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
Я написал что глобал индентичен таблице с двумя полями - аттрибут и его индекс - принципиальной разницы как записать индекс: '25081575/9148502606' или (25081575,9148502606) - нет. После этого Вы захотели узнать а как сделать поиск по полю не первого уровня. У себя вы делаете дополнительную ветвь и дублируете данные.

Давайте отвлечемся на минутку. Меня достало слушать про "дублируете данные". РСУБД не пишет
в индексах истинные значения полей, я правильно Вас понял? А что же там тогда пишется? Только,
пожалуйста, избавьте меня от сентенций типа "индексы не входят в логическую модель данных".
17 ноя 06, 22:43    [3418342]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ну я
OS/360
А в Каше можно осоздать временный объект с автоматическим уничтожением?

В локальных переменных.

С 5.2 появились и глобали.
17 ноя 06, 22:46    [3418354]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
jekaSQL
Member

Откуда: Бабруйск
Сообщений: 596
Sergei Obrastsov
SergSuper
Я написал что глобал индентичен таблице с двумя полями - аттрибут и его индекс - принципиальной разницы как записать индекс: '25081575/9148502606' или (25081575,9148502606) - нет. После этого Вы захотели узнать а как сделать поиск по полю не первого уровня. У себя вы делаете дополнительную ветвь и дублируете данные.

Давайте отвлечемся на минутку. Меня достало слушать про "дублируете данные". РСУБД не пишет
в индексах истинные значения полей, я правильно Вас понял? А что же там тогда пишется? Только,
пожалуйста, избавьте меня от сентенций типа "индексы не входят в логическую модель данных".


В индексы вполне могут писаться истинные значения полей. В кластерных индексах так вообще в листьях лежат реальные значения. Это даёт возможность в ряде(а на деле, так и в подавляющем количетве?) случаев вообще не дергать таблицу, а брать всё необходимое для запроса из индекса. Это рулит, когда(а почти всегда) объем индекса принципиально меньше размера таблицы. От программиста это не требует никаких усилий.
17 ноя 06, 23:03    [3418404]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Sergei Obrastsov
SergSuper
Я написал что глобал индентичен таблице с двумя полями - аттрибут и его индекс - принципиальной разницы как записать индекс: '25081575/9148502606' или (25081575,9148502606) - нет. После этого Вы захотели узнать а как сделать поиск по полю не первого уровня. У себя вы делаете дополнительную ветвь и дублируете данные.

Давайте отвлечемся на минутку. Меня достало слушать про "дублируете данные". РСУБД не пишет
в индексах истинные значения полей, я правильно Вас понял? А что же там тогда пишется? Только,
пожалуйста, избавьте меня от сентенций типа "индексы не входят в логическую модель данных".

Все гораздо прозаичнее, Оракл мне гарантирует что индекс синхронизирован с таблицей. Всегда. И писать ручками код синхронизирующий данные в индексе и таблице мне не надо. За меня этот код уже написали и отладили толковые ребята из Оракла. Моя же "боевая задача" своится к написанию "CREATE TABLE ..." и "CREATE INDEX ...". Кроме того в Оракле есть и реализация таблицы в виде дерева, IOT называется, там и синхронизировать не нужно ничего.

"Дублирование данных" (их избыточность, денормализованность), представляет собой проблему когда от программиста требуется писать код который обеспечивает согласованность этих данных (синхронность копий). В случае когда доступ к данным на чтение и запись имеет одновременно большое число клиентов, эта задача немедленно превращается в кошмар. Все на самом деле предельно просто: есть некая древовидная структура данных, ее элементы указывают друг на друга. В учебниках по программированию для наглядности обычно рассматривают двусвязный список, разница в данном случае несущественна. Теперь представьте что есть несколько читателей и писателей которые одновременно пытаются с ним работать. Что нужно сделать чтобы список не был разрушен таким доступом? Правильно, городить примитивы синхронизации, например семафоры. Многопоточное программирование с синхронизацией - это тот еще головняк. Дорого это и неэффективно, по сравнению с 2 строчкми на SQL.

А теперь представьте что таблиц и индексов у вас примерно столько же сколько их в SAP или Oracle Financials. Сколько вы будете "ручками" это все писать?
17 ноя 06, 23:57    [3418514]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
c127> А что там доказывать, на самом деле оценка сложности fullscan=n+F, дерева=log_k(n)+D, где F,D - константы, не зависящие от n.

Тут я немного ошибся, но по сути сказанного это ничего не меняет. F и D могут зависеть от n, только должны расти медленнее чем сложность алгоритма. Например алгоритм Дейкстры поиска кратчайшего пути имеет сложность O(n^2), инициализация занимает O(n) и состоит в обнулении массива длины n.

Зл0й
Sergei Obrastsov
Давайте отвлечемся на минутку. Меня достало слушать про "дублируете данные". РСУБД не пишет
в индексах истинные значения полей, я правильно Вас понял? А что же там тогда пишется? Только,
пожалуйста, избавьте меня от сентенций типа "индексы не входят в логическую модель данных".

Все гораздо прозаичнее, Оракл мне гарантирует что индекс синхронизирован с таблицей. Всегда. И писать ручками код синхронизирующий данные в индексе и таблице мне не надо. За меня этот код уже написали и отладили толковые ребята из Оракла. Моя же "боевая задача" своится к написанию "CREATE TABLE ..." и "CREATE INDEX ...". Кроме того в Оракле есть и реализация таблицы в виде дерева, IOT называется, там и синхронизировать не нужно ничего.

Я ж и говорю, что М это ассемблер, только работает медленнее и стоит больше. На ассемблере тоже можно написать абсолютно все, толькь нужно хорошо поднапрячься.

Sergei Obrastsov
c127
Sergei Obrastsov
Зл0й
А теперь скажите откровенно, вы сможете оргарнизовать в Каше например хэш-таблицу и обеспечить согласованное чтение из нее одновременно с ее изменением?

В Cache структура одна - дерево. Можно ли на ее основе сделать hash-таблицу, bitmap-карту
или что-то еще? Можно.

А ну-ка покажите если не сложно как на основе дерева создается хеш таблица.

Без проблем.
Вариант 1, самый простой - используем полученные hash-значения вместо индексов.
^data(number)=x1
^index(hash_x1)=number
Минус - разницы с обычным индексом никакой. Выигрыш возможен за счет уменьшения размера индекса и/или обхода принудительной сортировки индексов.
.................

А зачем хранить в ^index значение hash_x1, разве туда нельзя положить x1? Если x1 повторяются, а ведь могут, hash_x1 естественно тоже, то им соответствуют разные number, а у Вас number одно. Что будем делать?

Это не хеш, это пример того, как делаются ошибки, когда доходит до "все напишем ручками".
18 ноя 06, 01:02    [3418643]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Зл0й
А теперь представьте что таблиц и индексов у вас примерно столько же сколько их в SAP или Oracle Financials.

А сколько таблиц в R/3?
18 ноя 06, 01:03    [3418646]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
А зачем хранить в ^index значение hash_x1, разве туда нельзя положить x1?

А я и не храню. Вы вот поинтересовались возможностью организации hash, я и ответил.

c127

Если x1 повторяются, а ведь могут, hash_x1 естественно тоже, то им соответствуют разные number, а у Вас number одно. Что будем делать?

^index(hash_x1, number_1)
^index(hash_x1, number_2)
...
Не сложно было догадаться, правда ведь?

c127

Это не хеш, это пример того, как делаются ошибки, когда доходит до "все напишем ручками".

Это пример, что докопаться можно даже то телеграфного столба. Продолжайте в том же духе, ага.
18 ноя 06, 01:27    [3418664]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Зл0й
Все на самом деле предельно просто: есть некая древовидная структура данных, ее элементы указывают друг на друга. В учебниках по программированию для наглядности обычно рассматривают двусвязный список, разница в данном случае несущественна. Теперь представьте что есть несколько читателей и писателей которые одновременно пытаются с ним работать. Что нужно сделать чтобы список не был разрушен таким доступом? Правильно, городить примитивы синхронизации, например семафоры.

Достаточно блокировки. Причем эта возможность блокировки появилась в стандарте M еще 1977-го года.

Зл0й

Многопоточное программирование с синхронизацией - это тот еще головняк. Дорого это и неэффективно, по сравнению с 2 строчкми на SQL.

Все дело в подходе. Вы еще скажите, что каждый программист в команде, которая
работает над проектом в M, будет сам определять структуры общих данных, как ему захочется.
Конечно пишется программа, которая отвечает за работу с БД, с учетом блокировок, транзакций
и прочего, чего Вам так не хватает. Все остальные работают через нее. Таким образом снимается
вопрос о "прямом доступе к данным". Нет, я понимаю, что обязательно возникает вопрос "а вдруг...".
Ну так он и у Вас возникнет, если кто-то захочет сделать "DROP TABLE..."

Зл0й

А теперь представьте что таблиц и индексов у вас примерно столько же сколько их в SAP или Oracle Financials. Сколько вы будете "ручками" это все писать?

Во-первых, их будет намного меньше. Просто потому, что я не лимитирован способом хранения данных и потому что деревья представляют в этом плане другие возможности в организации хранения. Следовательно и индексов будет поменьше.
Больше всего времени, честно скажу, уходит на продумывание логической схемы данных и создание клиентского интерфейса.
18 ноя 06, 02:56    [3418722]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Sergei Obrastsov
Зл0й
Все на самом деле предельно просто: есть некая древовидная структура данных, ее элементы указывают друг на друга. В учебниках по программированию для наглядности обычно рассматривают двусвязный список, разница в данном случае несущественна. Теперь представьте что есть несколько читателей и писателей которые одновременно пытаются с ним работать. Что нужно сделать чтобы список не был разрушен таким доступом? Правильно, городить примитивы синхронизации, например семафоры.

Достаточно блокировки. Причем эта возможность блокировки появилась в стандарте M еще 1977-го года.

Если абстрагироваться от реализации то блокировка - частный (вырожденный) случай семафора. Блокировки чего конкретно? Как с deadlock'ами будем бороться если блокировки различной гранулярности? Опять что ли пишем нечто подобное оракловому ядру "ручками"? Повторять сакраментальный вопрос "Зачем писать то, что давным-давно написано и отлажено" надоело.

Sergei Obrastsov

Зл0й

Многопоточное программирование с синхронизацией - это тот еще головняк. Дорого это и неэффективно, по сравнению с 2 строчкми на SQL.

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

О чем и речь, придется написать Poor Man's Oracle (самопальный оракл) ручками на малоизвестном языке и потом поддерживать. Зачем такой непрактичный подход? Ну зачем так себя не любить? В приципе можно взять и переписать на ассмблере скажем Soalris. Весь, от и до. Намного быстрее работать он от этого не будет (современные оптимизирующие компиляторы весьма совершенны), но денег и времени на это уйдет фантастическое количество.

Sergei Obrastsov
Нет, я понимаю, что обязательно возникает вопрос "а вдруг...".
Ну так он и у Вас возникнет, если кто-то захочет сделать "DROP TABLE..."

Если у кого-то в Production environment программеры запростяк убивают нужные таблицы, значит у них в конторе "бардак валяется". В принципе в оракле вытащить из бэкапа таблицу и накатить логи до момента когда произошел Drop - не вопрос. В нормальных конторах такое не происходит. А вот отлов багов в сложных многопоточных приложениях с синхронизацией не прекращается никогда. Живые примеры - Informix, IBM, ... в общем с ресурсами у ребят все в порядке, дай Бог нам всем столько ресурсов. Но отлов багов вечен.


Sergei Obrastsov

Зл0й

А теперь представьте что таблиц и индексов у вас примерно столько же сколько их в SAP или Oracle Financials. Сколько вы будете "ручками" это все писать?

Во-первых, их будет намного меньше.

Предположим что их меньше в 10 раз. для 10 000 таблиц с 3мя индексами на таблицу имеем 30 000 индексов. Сколько десятков лет работы уйдет на отладку системы которая вручную поддерживает 3000 индексов? Думаю что подобный проект просто нереализуем по причине крайней непрактичности такого решения.

Sergei Obrastsov

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

Про "лимитирован способом хранения данных" поподробнее пожалуйста? Я вам приводил пример с IOT - то же самое дерево. Продумывание ЛОГИЧЕСКОЙ схемы. Золотые слова, открою вам "страшную тайну" в реляционных СУБД тоже продумывают логическую схему, и в IMS ее тоже продумывали. А как насчет продумывания физической схемы и отладку ея реализации в случае М-системы? Вот где собака-то порылась. Одно дело нарисовать логическую схему, а другое - написать некий "оракл в миниатюре" ручками.
18 ноя 06, 05:21    [3418756]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Croaton
Member

Откуда:
Сообщений: 11
"Физиология" внутреннего хранения: http://drus.boom.ru/StoreCache.pdf
Ну нет тут индексов в понимании РСУБД. Так-же как скачков к данным по логарифму. Так как соседние блоки в курсе друг о друге....
18 ноя 06, 05:45    [3418763]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Croaton
Member

Откуда:
Сообщений: 11
Продолжение про "физиологию"
При форсмажорных разрушениях диска, эта байда(дерево) прикольно восстанавливается(хоть и давненько, но попадал).
"Сбрасывается" информация о дереве(верхний блок указателей).
Остальные блоки несут(В СЕБЕ!) информацию о родителе и братьях.(Если Вы Иван Сергеевич, то имя отца очевидно(хотя не факт=) ). Кто-нибудь свою генеалогию собирал? - то-же самое.
50% метаний горшков на форуме, из-за непонимания внутреннего строения M.
А уж каша там название, или малаша это не главное.
Красиво написанный логарифмические перемещения - частный случай M.

А Sergei Obrastsov молодца держится, только зря...

M 10 лет,Oracle DBA, 4 года.
18 ноя 06, 06:17    [3418773]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Зл0й

О чем и речь, придется написать Poor Man's Oracle (самопальный оракл) ручками на малоизвестном языке и потом поддерживать. Зачем такой непрактичный подход? Ну зачем так себя не любить? В приципе можно взять и переписать на ассмблере скажем Soalris. Весь, от и до. Намного быстрее работать он от этого не будет (современные оптимизирующие компиляторы весьма совершенны), но денег и времени на это уйдет фантастическое количество.

Забавно. Видимо, мы выглядим как некие свихнувшиеся от безделья старички, решившие,
вопреки мнению умного большинства, построить велосипед с квадратными колесами? А
умное большинство, значить, весомо нас от этого отговаривает. Пока. Если не уймемся
начнет отлавливать и сдавать в психушку? Да не волнуйтесь Вы так, если все это фигня,
то беспокоиться просто не о чем. Наиграются в "мампсистов" и пойдут писать в SQL.

Зл0й

Если у кого-то в Production environment программеры запростяк убивают нужные таблицы, значит у них в конторе "бардак валяется". В принципе в оракле вытащить из бэкапа таблицу и накатить логи до момента когда произошел Drop - не вопрос. В нормальных конторах такое не происходит. А вот отлов багов в сложных многопоточных приложениях с синхронизацией не прекращается никогда. Живые примеры - Informix, IBM, ... в общем с ресурсами у ребят все в порядке, дай Бог нам всем столько ресурсов. Но отлов багов вечен.

Я, конечно, ничего не имею против Oracle. Но не слишком ли Вы его обожествляете? Странная
непогрешимость, не находите?

Зл0й

Предположим что их меньше в 10 раз. для 10 000 таблиц с 3мя индексами на таблицу имеем 30 000 индексов.

Простите, не могу представить. Даже 500 представить не могу. Это что, логическая схема такая?
Вы серьезно? И 30,000 индексов тоже не могу представить. Даже если печатать схемы по 10 таблиц на страницу и то получится книжуля в 1000 страниц. Я просто не верю, что в этой лабуде кто-то будет способен разобраться, не говоря уж о том, чтобы просто ее придумать.

Зл0й

Сколько десятков лет работы уйдет на отладку системы которая вручную поддерживает 3000 индексов? Думаю что подобный проект просто нереализуем по причине крайней непрактичности такого решения.

Понятия не имею. У Вас есть конкретные примеры? Или это из просто области больших чисел,
чтобы убивать оппонента огромным размахом мысли?

Зл0й

Про "лимитирован способом хранения данных" поподробнее пожалуйста?

Да сколько ж можно-то уже?

Зл0й

Я вам приводил пример с IOT - то же самое дерево.

Нет, не то же самое. Просто кто-то задумался, наконец, а не будет ли целесообразнее
хранить данные вместе с индексами. Похвальное достижение.

Зл0й

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

Вы знаете, я подозревал нечто подобное. И что нарыла собака, если не секрет? У Вас есть
душераздирающие примеры беспомощности M-систем? Или все на уровне "да я просто уверен"?
Это знаете-ли несерьезно.
18 ноя 06, 08:59    [3418825]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
Sergei Obrastsov

Простите, не могу представить. Даже 500 представить не могу.Это что, логическая схема такая?


Наверное здесь собака и порылась.
18 ноя 06, 09:53    [3418858]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
OS/360
Sergei Obrastsov

Простите, не могу представить. Даже 500 представить не могу.Это что, логическая схема такая?

Наверное здесь собака и порылась.

Вот оно оказывается в чем дело. В количестве "таблиц". То-то я чувствую, мне чего-то не хватает.
Ну что ж, обязуюсь исправиться и в ближайшем проекте доведу-таки их количество до приемлимого. Тысячи хватит или надо обязательно 10 тысяч? :)
18 ноя 06, 10:03    [3418864]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Рабочий проект

368 таблиц , из них штук 15- на прямом М доступе,- количество индексов усредненно умножайте на 2

Неясны "сомнения" что нужно "руками" что то синхронизовать.
В стандартной стратегии хранения - ничего делать не нужно - хотите добавляете индексы хотите удаляйте. Единственное что потребуется - в момент заведения построить его данные - что программируется и возможно через SQL и вызывается автоматом.

В таблицах с прямым доступом - вы ОДИН раз програмируете те процедуры что создают записи и все.

Да это походе на ассемблер да это возможно неоправданная рутина - но ее кол-во явно преувеличивают.
18 ноя 06, 11:38    [3418951]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Ptn
Рабочий проект

368 таблиц , из них штук 15- на прямом М доступе,- количество индексов усредненно умножайте на 2

Ой-ей. Да откуда ж такая дискретность-то?! Разве что справочники распихать по отдельным массивам, тогда можно понять. НО ЗАЧЕМ?! Можете намекнуть на принадлежность проекта?
18 ноя 06, 12:06    [3418991]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
Очередной ответ - созданием нужного индекса конечно. По-моему, это очевидно. Более того, в предложенной структуре он есть.
Бла-бла-бла... Т.е. М-система сама подумает и создаст нужный индекс?
Фигею просто. Чтобы вытянуть из Вас признание, что без дополнительного индекса будет точно такой же фуллскан потребовалось задать вопрос трижды! :-))) И то, Вы всё-равно извернуться пытаетесь... Некрасиво.
18 ноя 06, 12:11    [3418999]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Т.к. в этой ветке диалог ведётся чуть более конструктивно, задам этот вопрос тут. В свете описанных в соседней ветке занимательных приключений американца в... Каше, не мог бы Sergei Obrastsov, или кто-то другой, практикующий разработку с использованием этой системы, рассказать, как решаются вопросы с контролем версий, отладкой, бакапами?
18 ноя 06, 12:32    [3419034]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Sergei Obrastsov
Очередной ответ - созданием нужного индекса конечно. По-моему, это очевидно. Более того, в предложенной структуре он есть.
Бла-бла-бла... Т.е. М-система сама подумает и создаст нужный индекс?
Фигею просто. Чтобы вытянуть из Вас признание, что без дополнительного индекса будет точно такой же фуллскан потребовалось задать вопрос трижды! :-))) И то, Вы всё-равно извернуться пытаетесь... Некрасиво.

Меня уже начинает пугать степень непонимания. Я уже 100 раз сказал, что создаю индексы самостоятельно. Я привел структуру, в которой эти индексы четко показаны. Чего Вам еще не
хватает, чтобы понять, что Я ИХ ДЕЛАЮ САМ? У меня нет фуллскана, потому что индексы зашиты
в структуру и я сразу ориентирую программу на их использование. Мою программу, мной написанную. Какие еще вопросы будут?

Уф... Еще раз, надеюсь последний.
Предпосылка: утверждение, что таблица с двумя полями адекватна дереву.
Дано: дерево. рабочее, с развешанными внутри перекрестными ссылками для повышения производительности.
Получено: таблица с двумя полями.
Вопрос 1: адекватны ли они внешне?
Ответ 1: допустим.
Вопрос 2: адекватны ли они по производительности?
Ответ 2: нет. таблице необходимы дополнительные индексы. в дереве они уже есть.
Вывод 1: нефиг сравнивать.
Вывод 2: нефиг говорить необдуманно.
Вывод 3: нефиг прятаться за возможностями системы. если речь идет о структуре, то и
надо говорить о ней, как о полноценном объекте. а иначе - Вывод 1.

P.S. Прошу прощения за резкость ответа.
18 ноя 06, 12:38    [3419049]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 34 35 36 37 38 [39] 40 41 42 43 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить