Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 86 87 88 89 90 [91] 92 93 94 95 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Изопропил
Member

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

Мы ищем не "возможное место нахождения кошелька", а сам кошелек. :)


Мы, Николай Второй?
15 янв 07, 21:18    [3644998]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Sergei Obrastsov
Vlad2005
Sergei Obrastsov
DocAl
decaml

наша задача дать точную координату юзеру - где может лежать его кошелек
...И говорит человеческим голосом, поищи, мол, Вася, в заднем кармане брюк. Нет? А в куртке? Тоже нет? Ну тогда кто ж тебя, алкоголика знает, где ты его потерял!

Прекрасное и доходчивое описание select'а. :)


Неправильная ответа...

SELECT вернет ВСЕ возможные места ;-))))

Мы ищем не "возможное место нахождения кошелька", а сам кошелек. :)


Дык, мон шер, WHERE -то и даст ограничение по местонахождению. Ву компреме?
;-))))
15 янв 07, 21:33    [3645023]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Vlad2005
Sergei Obrastsov
Vlad2005
Sergei Obrastsov
DocAl
decaml

наша задача дать точную координату юзеру - где может лежать его кошелек
...И говорит человеческим голосом, поищи, мол, Вася, в заднем кармане брюк. Нет? А в куртке? Тоже нет? Ну тогда кто ж тебя, алкоголика знает, где ты его потерял!

Прекрасное и доходчивое описание select'а. :)


Неправильная ответа...

SELECT вернет ВСЕ возможные места ;-))))

Мы ищем не "возможное место нахождения кошелька", а сам кошелек. :)


Дык, мон шер, WHERE -то и даст ограничение по местонахождению. Ву компреме?
;-))))

А я и не спорю. Вот и получается поиск, тут есть? - нет, тут есть? - нет, тут есть? - о, нашли. :)
15 янв 07, 22:58    [3645141]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
зачем искать

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

это принцЫп м-программирования
15 янв 07, 23:50    [3645227]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Ptn
c127>>Ничего сложного Вы не увидели потому, что как и Sergei Obrastsov в силу необразованности просто не представляете о чем идет речь.

Это с вашей точки зрения - цитирую вашу ссылку

Таким образом, 11 следует разместить в списке, на начало которого указывает hashTable[3]


объясните чем hashTable[3] отличаеться ^hashTable(3)

Про физический уровень - слов не нужно.
И про то что я якобы опять ничего не понял тоже.
Это только убедить меня что Вы читая "В Cache структура одна - дерево" так и не поняли что это наиболее распространенный метод работы c реальной структурой данных именуемой как разреженные многомерные масcивы.

Чем массив hashTable[3] отличается массива ^hashTable(3) объяснить не затруднит ? Нет ?

Не затруднит, если Вы объясните, в чем проблема. Научитесь приводить ссылки. Откуда цитата? В чем именно вопрос?


>>Цирк. А теперь почитайте внимательнее, что именно Вам заливают.

Прочитав ту ветку я сделал вывод что Цирк в том Вы так и не поняли о чем RUS000 говорил - зато выдумали "общеупотребимые" индексы и еще несколько мифов.

Какие мифы, кто именно говорил? Вы упоминаете топик, делаете относительно него какие-то утверждения, привдите цитаты и все станет ясно, а то может не поняли о чем идет речь и никаких мифов нет.
16 янв 07, 03:33    [3645488]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
c127
Не затруднит, если Вы объясните, в чем проблема. Научитесь приводить ссылки. Откуда цитата? В чем именно вопрос?

Какие мифы, кто именно говорил?


А если читать внимательно ? Уже цитировал " Re: Каше vs. Фокс... 2384455"
c127

Это не бинарное-дерево, у дерева скорость поиска от количества данных зависит логарифмичесаки, а у хеш индекс - константа. Дерево можно использовать при запросах вида Z>10, хеш индекс нельзя. Насколько я понимаю хеш индекс это хеш таблица.
http://algolist.manual.ru/ds/s_has.php


http://algolist.manual.ru/ds/s_has.php
...Таким образом, 11 следует разместить в списке, на начало которого указывает hashTable[3]...


Как видите в приведенной вами ссылке тоже к имени переменной добавили hash.
Еще раз в чем проблема у SergSuper ?

Чем массив hashTable[3] отличается массива ^hashTable(3) объяснить не затруднит ?
Нет ?
А от двумерный массив от таблицы ?

c127
Мы как-то по-разному понимаем индексы. Индекс на длину программы не влияет, он влияет только на эффективность. Похоже что в М индекс нужно не толко поддерживать руками, но и явно указывать системе, что его нужно использовать, иначе она его не увидит. Точнее даже не указывать, что его нужно использовать, а использовать вручную вместо основного дерева. Но тогда это не индекс, это просто другая структура данных, в РСУБД тоже иногда так поступают, но этого лучше избегать пока возможно.

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


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


c127
Да, но к сожалению весь СУБД мир (а это почти на 100% РСУБД мир) понимает индекс не так как Вы.


Rus000
старался никогда не говорить за всех ...


c127
Есть общепринятые понятия. Индекс в современной РСУБД это НЕ то же самое, что таблица, которая должна бы получиться, если принять Ваш подход к индексам. Можно почитать хотя бы Дейта. О доле рынка который приходится на РСУБД даже спорить лень. Вот и получается (пока что), что почти весь СУБД мир понимает индекс не так как Вы, хотя Вы конечно вправе использовать свое определение, если все-таки его сформулируете.


[выделение мое]

И что мы видим ? А видим мы РСУБД-шную упертость. У вас де иконки не сиреневого цвета.

У Rus000 даже те самые две процедуры, где нужно добавлять индексы, прописаны - но сравнивая эту ветку и ту вижу что все его объяснения пропали без толку .

ЗЫ: Индекс всю жизнь был структурой данных призванный для ускорения оброботки основной информации, поддержки уникальности полей/ключей и т.д.
Как право чего либо называться индексом связано не с его назначением, а исключительно со способом его реализации - это видимо одним РУСБД-никам дано решать.
16 янв 07, 08:38    [3645693]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Ptn
[quot Lepsik]
Предложения не связаны. Наличие штата программистов не означает недоверия к 3-им фирмам.


Связаны фактами. С какой стати банку кормить чужие конторы.

---Как и наоборот - штат программистов существует вовсе не из-за недоверия к 3-им фримам.

Естественно причин много и совершенно нет причин отдавать разработки на сторону за тройную стоимость.

Ptn
Что до крупнейших банков - то другие в расчет не берем ?
Исходя из ваших же предложений - спрошу еще раз, почему, например, существует 3-я фирма Програмбанк ? Отзывы недоверчивых банков справа


просто убили наповал тремя корманным банками, общая доля которых на банковском рынке и десятой доли процента не потянет. Скромнее надо быть : "При этом в реальных приложениях СУБД Cache' показывает производительность в двадцать раз выше, чем у реляционных СУБД", глядишь бы кто-нибудь вам и поверил.
16 янв 07, 09:09    [3645776]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Ptn
Что до крупнейших банков - то другие в расчет не берем ?
Исходя из ваших же предложений - спрошу еще раз, почему, например, существует 3-я фирма Програмбанк ? Отзывы недоверчивых банков справа



Опять же копался в ваших линках и нашел любопытную цитату :

"Банк Chase Manhattan использует приложения, реализованные на продуктах InterSystems, для ведения центральной базы данных, обработки депозитных вкладов и ссуд, on-line ввода данных, управления финансами, автоматизации офисной деятельности и работы сетей кассовых аппаратов"

Пытался найти что говорит сам банк о своей базе :

Oracle Corp, one of the largest providers of software for e-business, announced an agreement with The Chase Manhattan Bank naming Oracle a strategic technology provider to the nation's second largest bank.

Using Oracle database, data warehouse and business intelligence technologies, it's easier for us to determine which of our programs and offerings are most profitable. Through our Oracle data warehouse, we have access to a new level of in-depth, detailed product and account-level profitability information," said Charles DeFelice, vice president of Chase Business Services. "Oracle's database technologies and applications give us the scale and sophisticated analysis tools we need to pinpoint specific areas of profitability. By clearly reflecting the entirety of the customer relationship, we expect to dramatically improve our client relationships."

[url=http://www.taborcommunications.com/dsstar/00/0822/102061.html[/url]

Я может неправильно ищу ?
16 янв 07, 09:22    [3645827]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Lepsik>>Связаны фактами. С какой стати банку кормить чужие конторы.

Логическое допущение высосанное из пальца

>>Естественно причин много и совершенно нет причин отдавать разработки на сторону за тройную стоимость.

Логическое допущение высосанное из пальца

>>просто убили наповал тремя корманным банками, общая доля которых на банковском рынке и десятой доли процента не потянет. Скромнее надо быть :

Значит ленту новостей не осилили. Ну что ж вы писали что "не знаете какой " теперь знаете.

Далее ... я уже спрашивал
Ptn
Что до крупнейших банков - то другие в расчет не берем ?


Выходить таки да ? Знаете ... Скромнее надо быть.

А факт того что эта, отдельно известная мне, 3-я компания производящая банковский софт - далеко НЕ единственная на весь наш шарик - оставляю за Вами.

"При этом в реальных приложениях СУБД Cache' показывает производительность в двадцать раз выше, чем у реляционных СУБД"

Напишите им письмо. Я не работаю в Програмбанке.
16 янв 07, 10:41    [3646327]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Lepsik
Опять же копался в ваших линках и нашел любопытную цитату :

"Банк Chase Manhattan использует приложения, реализованные на продуктах InterSystems, для ведения центральной базы данных, обработки депозитных вкладов и ссуд, on-line ввода данных, управления финансами, автоматизации офисной деятельности и работы сетей кассовых аппаратов"

Пытался найти что говорит сам банк о своей базе :

Oracle Corp, one of the largest providers of software for e-business, announced an agreement with The Chase Manhattan Bank naming Oracle a strategic technology provider to the nation's second largest bank.

Using Oracle database, data warehouse and business intelligence technologies, it's easier for us to determine which of our programs and offerings are most profitable. Through our Oracle data warehouse, we have access to a new level of in-depth, detailed product and account-level profitability information," said Charles DeFelice, vice president of Chase Business Services. "Oracle's database technologies and applications give us the scale and sophisticated analysis tools we need to pinpoint specific areas of profitability. By clearly reflecting the entirety of the customer relationship, we expect to dramatically improve our client relationships."

[url=http://www.taborcommunications.com/dsstar/00/0822/102061.html[/url]

Я может неправильно ищу ?


Напишите им письмо. :) Я не работаю в Chase Manhattan. И уж тем более не пишу новости за ПрограмБанк.

Или ищите лучше ... ведь можно спросит и причем здесь taborcommunications ? :)
16 янв 07, 10:46    [3646373]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Вот вам еще

PS: Элементраное [g банковское ПО] в Опере выдает.
16 янв 07, 11:00    [3646488]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
decaml
Member

Откуда:
Сообщений: 228
Работа банка - тонкая штучка.
К примеру, берет у клиента вклад 10 руб – под 5% годовых.
Автоматически под эти 10 руб – банк получает у государства еще 90 руб под 11% годовых.
И потом выдает 100 руб кредита под 20% годовых (в этом фишка – выдать кредиты).

Итого: 1 руб клиента с 5% расходностью дает банку 10 руб с 9% доходностью.

Если с банком подружиться, то под залог своих 10 руб можно там легко получить 100 руб (к примеру на строительство многоэтажного дома) – это называется правило рычага, и в этом случае ты начинаешь работать как банк – твой 1 руб превратился в 10 руб.
16 янв 07, 12:32    [3647445]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Dried Gagarin
Member

Откуда: Kaluga, Russia
Сообщений: 527
decaml
Работа банка - тонкая штучка.

Это к чему? Поумничать схотел?
16 янв 07, 12:53    [3647655]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
decaml
Работа банка - тонкая штучка.
К примеру, берет у клиента вклад 10 руб – под 5% годовых.
Автоматически под эти 10 руб – банк получает у государства еще 90 руб под 11% годовых.

Блин, ну зачем писать про то, о чем не имеете ни малейшего представления? Что про СУБД, что про банки
(На самом деле не возьмёт 90 руб, а отдаст из эти десяти два руб государству как резерв и без всяких процентов)
16 янв 07, 14:23    [3648540]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
decaml
Member

Откуда:
Сообщений: 228
SergSuper
decaml
Работа банка - тонкая штучка.
К примеру, берет у клиента вклад 10 руб – под 5% годовых.
Автоматически под эти 10 руб – банк получает у государства еще 90 руб под 11% годовых.

Блин, ну зачем писать про то, о чем не имеете ни малейшего представления? Что про СУБД, что про банки
(На самом деле не возьмёт 90 руб, а отдаст из эти десяти два руб государству как резерв и без всяких процентов)


закрыли тему
просто тут вот не хватает колонки с цифрами об обьемах фактического рефинансирования коммерческих банков
http://www.cbr.ru/print.asp?file=/statistics/credit_statistics/refinancing_rates.htm

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

налицо недоработка хваленого "многомиллионо-планового" запроса
16 янв 07, 20:01    [3650877]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
с127
Guest
Ptn
c127
Не затруднит, если Вы объясните, в чем проблема. Научитесь приводить ссылки. Откуда цитата? В чем именно вопрос?

Какие мифы, кто именно говорил?


А если читать внимательно ? Уже цитировал " Re: Каше vs. Фокс... 2384455"
c127

Это не бинарное-дерево, у дерева скорость поиска от количества данных зависит логарифмичесаки, а у хеш индекс - константа. Дерево можно использовать при запросах вида Z>10, хеш индекс нельзя. Насколько я понимаю хеш индекс это хеш таблица.
http://algolist.manual.ru/ds/s_has.php


http://algolist.manual.ru/ds/s_has.php
...Таким образом, 11 следует разместить в списке, на начало которого указывает hashTable[3]...


Как видите в приведенной вами ссылке тоже к имени переменной добавили hash.

Там кроме того, что к имени добавили "hash", произведены еще кое-какие действия. А Sergei Obrastsov посчитал, что одного названия вполне достаточно. Если я жигули назову мерседесом, он мерседесом не станет, но если мерседесом назову автомобиль, у которого мерседесовский двигатель, кузов, ходовая и все остальное, и собран он на мерседесовских заводах, то это будет мерседес. Названия одинаковые, а автомобили очень даже разные.

Ptn
Еще раз в чем проблема у SergSuper ?

Спросите у него, он как раз появился.

Ptn

Чем массив hashTable[3] отличается массива ^hashTable(3) объяснить не затруднит ?
Нет ?

Это зависит от того, что такое ^hashTable(3), в частности как там осуществляется адресация. Что такое массив я себе представляю.
Хотя если прочитать ссылку, то все становится понятно. Для особо одаренных подсказываю: обратите внимание на то, как именно строится хеш-код в приведенной ссылке, как он хранится и сравните это с тем, как это делает Sergei Obrastsov в своем замечательном примере. Хотя в том обсуждении, которое Вы процитировали, это все есть в явном виде, если Вы все еще не поняли, то вряд ли дойдет сейчас.

Ptn


c127
Мы как-то по-разному понимаем индексы. Индекс на длину программы не влияет, он влияет только на эффективность. Похоже что в М индекс нужно не толко поддерживать руками, но и явно указывать системе, что его нужно использовать, иначе она его не увидит. Точнее даже не указывать, что его нужно использовать, а использовать вручную вместо основного дерева. Но тогда это не индекс, это просто другая структура данных, в РСУБД тоже иногда так поступают, но этого лучше избегать пока возможно.

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


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


c127
Да, но к сожалению весь СУБД мир (а это почти на 100% РСУБД мир) понимает индекс не так как Вы.


Rus000
старался никогда не говорить за всех ...


c127
Есть общепринятые понятия. Индекс в современной РСУБД это НЕ то же самое, что таблица, которая должна бы получиться, если принять Ваш подход к индексам. Можно почитать хотя бы Дейта. О доле рынка который приходится на РСУБД даже спорить лень. Вот и получается (пока что), что почти весь СУБД мир понимает индекс не так как Вы, хотя Вы конечно вправе использовать свое определение, если все-таки его сформулируете.


[выделение мое]

И что мы видим ? А видим мы РСУБД-шную упертость. У вас де иконки не сиреневого цвета.

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

Ptn

У Rus000 даже те самые две процедуры, где нужно добавлять индексы, прописаны - но сравнивая эту ветку и ту вижу что все его объяснения пропали без толку .

ЗЫ: Индекс всю жизнь был структурой данных призванный для ускорения оброботки основной информации, поддержки уникальности полей/ключей и т.д.
Как право чего либо называться индексом связано не с его назначением, а исключительно со способом его реализации - это видимо одним РУСБД-никам дано решать.

Еще раз повторяю: индекс это не таблица. Внутри РСУБД оно может быть реализовано как таблица, но РСУБД программиста это не интересует, он не тратит время на создание и поддержку индекса и его код не зависит от того, есть там индекс или нет. Еще раз читайте внимательно: программист не тратит на все это свое драгоценное время. М-программист тратит время на создание и поддержку индекса. И "те же самые" две процедуры Rus000 должен написать РУКАМИ, а РСУБД-шинк о них не думает вообще. А как показывает пример V52 ( https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=85#3623156 ), который в элементарном примере забыл всего-навсего об удалении и изменении данных, руками пишется зачастую с ошибками.
17 янв 07, 00:52    [3651270]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
с127
Там кроме того, что к имени добавили "hash", произведены еще кое-какие действия. А Sergei Obrastsov посчитал, что одного названия вполне достаточно. Если я жигули назову мерседесом, он мерседесом не станет, но если мерседесом назову автомобиль, у которого мерседесовский двигатель, кузов, ходовая и все остальное, и собран он на мерседесовских заводах, то это будет мерседес. Названия одинаковые, а автомобили очень даже разные.

Это было бы смешно, если бы не было так грустно. Я наверно должен был привести алгоритм hash-функции, заверенный сертификатом от Microsoft или кого-либо еще, а также выписку из протокола
тестировочной комиссии, заверяющем о соответствии примененных методов методам, одобряемым
в РСУБД? По-моему это несерьезно уже. Я вообще-то рассчитывал что общаюсь со взрослыми людьми, которые понимают что под словом hash подразумевается результат действия hash-функции, а hash в названии массива подразумевает hash-таблицу. Но если это настолько недоступно, то конечно я беру свои слова обратно. И еще, алгоритма hash-функции меня не спрашивали, меня спрашивали об организации таблицы. Я показал. Не нравится - не ешьте,
зачем слюни-то на весь форум распускать?

с127

Это зависит от того, что такое ^hashTable(3), в частности как там осуществляется адресация. Что такое массив я себе представляю.
Хотя если прочитать ссылку, то все становится понятно. Для особо одаренных подсказываю: обратите внимание на то, как именно строится хеш-код в приведенной ссылке, как он хранится и сравните это с тем, как это делает Sergei Obrastsov в своем замечательном примере. Хотя в том обсуждении, которое Вы процитировали, это все есть в явном виде, если Вы все еще не поняли, то вряд ли дойдет сейчас.

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

с127

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

Я безумно счастлив за РСУБД программиста. У него высвобождается "драгоценное время" для составления многостраничных запросов.

с127

М-программист тратит время на создание и поддержку индекса. И "те же самые" две процедуры Rus000 должен написать РУКАМИ, а РСУБД-шинк о них не думает вообще.

Я счастлив за РСУБД-шника и страшно огорчен за M-программиста. Ведь ему не приходит в голову
выделить работу с БД в отдельные процедуры и он принужден размазывать обращение к глобалям
по всем программам. А во что выливается изменение хотя бы одной ссылки - просто страшно подумать.

с127

А как показывает пример V52 ( https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=85#3623156 ), который в элементарном примере забыл всего-навсего об удалении и изменении данных, руками пишется зачастую с ошибками.

А еще он забыл нарисовать в этом примере GUI и указать пароли для входа, а также свою фотографию, семейное положение и отношение к президенту США.
То чем занимаетесь Вы в последнее время - уже не глупость, это просто паранойя.
Я понимаю что хочется испинать ногами покусившихся на святое, но попробуйте делать это нормальным путем.
M есть за что упрекнуть и SQL есть за что уважать.
17 янв 07, 02:00    [3651313]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
с127 >>Это зависит от того, что такое ^hashTable(3), в частности как там осуществляется адресация.

Например ? ваши предположения ? (для справки для set a=array(22) используеться hash)

>>Для особо одаренных подсказываю: обратите внимание на то, как именно строится хеш-код в приведенной ссылке, как он хранится и сравните это с тем, как это делает Sergei Obrastsov в своем замечательном примере.

Я уже писал - нет никаких техническим проблем реализовать всё ИМЕННО так как написано по вашей ссылке. Что не исключает альтернативных реализаций.

Тут как и с индексами - суть определяет алгоритм, а не способ его реализации.

Так же как и важно не то что писал Сергей, а то что РУСБД-ки создают очередной миф о способах реализации hash индекса мупсерами.

>>Еще раз повторяю: индекс это не таблица.

Вы знаете ? я даже выделил места - что было явно видно что о ТАБЛИЦE разговор завели Вы.
Rus000 использовал слово структура - разные, знаете ли, вещи.

Внутри РСУБД оно может быть реализовано как таблица, но РСУБД программиста это не интересует, он не тратит время на создание и поддержку индекса и его код не зависит от того, есть там индекс или нет.

Да на здоровье - РСУБД программист тратит время на написание create index бла бла бла, М-программист тратит время на добавление строки set ^GlobalIndex(бла бла бла)= ...

>>И "те же самые" две процедуры Rus000 должен написать РУКАМИ, а РСУБД-шинк о них не думает вообще.

Вам знакомо выражение написать 1-н раз ?

Всё эти тыкание что мол у вас всё РУКАМИ со стороны РСУБД-шинков есть демагония и придирки по "неправильному" цвету иконок.

>>А как показывает пример V52

Я вам тоже выкладывал пример (и Russ000 тоже - объектный пример) - ткните пальцем где мы там что руками делаем ?

М-код уже просмотрели ?
17 янв 07, 08:29    [3651530]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
с127

Еще раз читайте внимательно: программист не тратит на все это свое драгоценное время. М-программист тратит время на создание и поддержку индекса. И "те же самые" две процедуры Rus000 должен написать РУКАМИ, а РСУБД-шинк о них не думает вообще.


примерное усредненное распределение моего времени
(м-программист)

1 час --кофе и политика - общение со товарищами
1 час --интернет и переписка
1 час --подключением новых м-пользователей - консультации - договоры
1 час --уточнение постановок задач вместе с прежними пользователеми
1 час --за рулем - поездки для деловых и личных встреч
1 час --программирование - внесение доработок и изменений в
существующие прикладные м-системы
1 час --программирование - развитие базовой м-системы - новые идеи
1 час --обед и личные дела
==================
игого 8 часов

более сотни обьектов-пользователей

что тут можно сократить при переходе на РСУБД ?
17 янв 07, 09:34    [3651729]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, MX!
Ты пишешь:

MX
MA> что тут можно сократить при переходе на РСУБД ?
ВСЁ!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

17 янв 07, 09:40    [3651783]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Мимопроходящий

Привет, MX!
Ты пишешь:

MX
MA> что тут можно сократить при переходе на РСУБД ?
ВСЁ!

Имеется в виду, что тогда он все 8 часов не будет думать об индексах?
17 янв 07, 09:46    [3651820]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, Sergei!
Ты пишешь:

Sergei
MX
Мимопроходящий
MA>> что тут можно сократить при переходе на РСУБД ?

> ВСЁ!
SO> Имеется в виду, что тогда он все 8 часов не будет думать об индексах?

Парни, имхо, имеют место быть потуги сравнить
уклад жизни и распорядок дня православного монаха
с укладом жизни и распорядком монаха из Шаолиня.
(неважно, кто есть ху, как говаривал Горбачев)
При этом, решительно игнорируются различия мировоззрения
одного и другого, равно как и различия теософских постулатов.

Спрашивается: ну и хули?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

17 янв 07, 10:10    [3652042]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Мимопроходящий Парни, имхо, имеют место быть потуги сравнить
уклад жизни и распорядок дня православного монаха
с укладом жизни и распорядком монаха из Шаолиня.


Ты только заметил ? o_O

>>Спрашивается:

Слово предоставляется РСУБД-никам.
17 янв 07, 10:22    [3652151]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MX -- ALEX

1 час --программирование - развитие базовой м-системы - новые идеи

Я предлагаю Вам этот час сэкономинть: из того что мы здесь читали, все-таки м-системам, скорее всего, никакое развитие уже не поможет. Они, скорее, производят впечатление каких-то устарвших идей. Кроме Каши, М-системы в лучшем случае - СУБД первого поколонеия. Ну какие тут новые идеи?

Лучше перекиньте это час в
MX -- ALEX

1 час --кофе и политика - общение со товарищами
17 янв 07, 10:40    [3652296]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
vadiminfo
MX -- ALEX

1 час --программирование - развитие базовой м-системы - новые идеи

Я предлагаю Вам этот час сэкономинть: из того что мы здесь читали, все-таки м-системам, скорее всего, никакое развитие уже не поможет. Они, скорее, производят впечатление каких-то устарвших идей. Кроме Каши, М-системы в лучшем случае - СУБД первого поколонеия. Ну какие тут новые идеи?

Лучше перекиньте это час в
MX -- ALEX

1 час --кофе и политика - общение со товарищами


однако M-технология развивается -
как это ни удивительно многим РСУДБэшникам
и перспективы вполне нормальные

я уже писал выше что наши девочки-кашистки под руководством
технологов сделали приличную систему для сортопрокатного цеха

но самое интересное что годом ранее система уже была сделана на
РСУБД специальными мужиками асутепешниками - но забракована
и снята с эксплуатации - а новая - на CACHE - прижилась сходу

так что я не уверен в Вашей правоте

спасибо за совет, но Ваш вариант - не проходит

работаем мы кстати на CACHE 5.2
хотя GT.M тоже не стоит на месте
17 янв 07, 12:03    [3653145]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 86 87 88 89 90 [91] 92 93 94 95 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить