su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Vladimir Pavlikov                    2:5020/400     23 Jan 2001  16:47:02
 To : All
 Subject : Re: Помогите в выбором СУБД под винды...
 -------------------------------------------------------------------------------- 
 

 > <2.07b5.BFYZ.G7EEQT@dim.sartax.saratov.su>
 > <2.07b5.5V9L.G7F1JM@dim.sartax.saratov.su>
 > <2.07b5.FJUT.G7KOZS@dim.sartax.saratov.su>
 
 From: "Vladimir Pavlikov" <pvv@soil.msu.ru>
 Hello! "Oleg V. Boldyrev" <olegb@dim.sartax.saratov.su> wrote:
 
 > > Откуда такая уверенность? Оптимизатор опирается в работе и на некие
 >   Действительно... Буду скромнее :)
 
 :)
 
 > > Я не говорю уже о том, что, сервер "сойдет с ума", полу-
 > > чив от функции невалидный индекс...
 
 >     Опасно, конечно. Hо ведь Extended procedureds можно добавлять, а от них
 >   тоже может сойти.
 
 Цели и задачи отличаются. Процедуры - это функциональность пользователя, тут
 уж... раз надо, так надо. Хеширование - это подмеханизм для решения внутренней
 задачи самого сервера.
 
 >   А потом над этой битовой цепочкой
 >   выполнить какое-то преобразование, то бишь суммировать их с каким-то весом
 >   и результат взять по модулю, не знамо какому. Можно ли с помощью какой-то
 >   наперед заданной хешь функции достичь равномерности для общего случая? Черт
 >   его знает, математика хитрая наука:)
 
 Можно, по указанной причине :) А вот модуль "незнамо какой" именно для твоего
 коллбэка - для сервера он всегда известен.
 > Hо вероятно, что используется многопро-
 >   ходный алгоритм, битовая цепочка анализируется на предмет наиболее часто
 >   изменяющихся мест и соответственно подбирется весовая функция. Что-то же
 >   там тарахтит во время set statistics.
 
 Думаю, как раз хеши-то во время set statistics не считаются. Для тарахтения
 много других оснований :)
 --
           Владимир Павликов.
 Отправлено через сервер Talk.Ru - http://www.talk.ru
 --- ifmail v.2.15dev5
  * Origin: Fidolook Express 2.000  www.fidolook.da.ru (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор