Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2006.10.08;
Скачать: [xml.tar.bz2];

Вниз

поиск "дыр" в ID   Найти похожие ветки 

 
Barloggg   (2006-09-18 17:05) [40]

о это просто поэма... можно даже сказать произведение искусства.

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

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

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

и таких оглавлений для каждого поля наделано...

и тоже есть процедура оптимизация, которая трет нафиг все оглавления, потом компонует новый файл и восстанавливает оглавления по новой. ну не совсем в таком порядке, но примерно так.

вот такая вот история...


 
Johnmen ©   (2006-09-18 17:16) [41]


> Barloggg   (18.09.06 17:05) [40]


История интересная. Имеет право на жизнь, если данные БД подвергаются модификации регламентно и централизованно. Желательно как можно реже.
Иначе это полные тормоза...


 
Shaman_ ©   (2006-09-18 17:29) [42]

[40] Barloggg   (18.09.06 17:05)
А чем обусловлен такой гемморой? На выполнение LIKE запроса по текстовому полю обычно требуется меньше 100 миллисекунд (естественно зависит от многих факторов). На крайний случай можно на контекстный поиск выделить отдельный поток чтобы небыло задержек при выполении запроса


 
MsGuns ©   (2006-09-18 17:51) [43]

>Barloggg   (18.09.06 17:05) [40]

Да уж..
Не нравится мне как медленно ездит обычный велосипед.
И решил я изобрести свой: с квадратными колесами, ручными педалями и ножным поворотом. Медленно ездил.. Тогда заменил квадратные колеса на восьмиугольные - скорость резко возросла. А когда додумался крутить педали ногами стала просто космической ;))

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


 
Barloggg   (2006-09-19 09:21) [44]

гы... все такие умные аж смешно...

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

и вообще это приложение должно работать всего полдня в месяц... зато работать должно шустро...


 
Anatoly Podgoretsky ©   (2006-09-19 09:25) [45]

Где ты видел сортированые базы? Что то новое в самолетостроении.


 
MsGuns ©   (2006-09-19 09:30) [46]

>Barloggg   (19.09.06 09:21) [44]
>можно подумать я тут что-то новое изобрел. хи-хи.

Вот это:

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


я полагаю вполне тянет на изобретение. И даже может претендовать на приз "за самое бесполезное изобретение года".

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

Поподробнее про "сортированные" базы, пожалуйста, а то я еще недостаточно насмеялся с утра ;)

>и вообще это приложение должно работать всего полдня в месяц... зато работать должно шустро...

"В пьянстве замечен не был, однако по утрам пил холодную воду" (с)


 
Anatoly Podgoretsky ©   (2006-09-19 09:41) [47]

В пьянстве замечен не был, однако по утрам читал форум Начинающие


 
MikhailV   (2006-09-19 09:53) [48]


> приз "за самое бесполезное изобретение года".

+1


 
SergP ©   (2006-09-19 10:28) [49]

> [14] Johnmen ©   (16.09.06 22:16)
> Ещё раз прошу любителей затыкать дыры обосновать своё желание.
> Без детского сада...


Например:
1.
Когда-то пытался писать клиент для форума phpBB.
Так там вычисление удаленных тем и сообщений иначе как по поиску дыр не получилось бы сделать.

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


 
MsGuns ©   (2006-09-19 11:00) [50]

>SergP ©   (19.09.06 10:28) [49]
>Например:
>Так там вычисление удаленных тем и сообщений иначе как по поиску дыр не получилось бы сделать.

Если не получилось у Вас - это не значит, что нельзя вообще.

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

Вы вообще читаете то, что пишут другие ? Или бегло просматриваете "по диагонали" ? Было сказано, что

 счетчики (читай ID) надо использовать стого по назначению

а не пытаться соорудить из них какие-то там "нумера". Сколько раз Вам надо это объяснять ?
А теперь про "номер документа" и "требуют, шоб само определяло".
Во-первых "номер документа" - это вещь весьма ответственная и компьютерная "отсебятина" в этом плане может в некоторых случаях просто мешать оператору и даже раздражать. Поэтому желательно определение автономера выделить в отдельную сервисную функцию, которую пользователь будет использовать по мере надобности.
Во-вторых, что мешает сделать определение номера в виде стандартного универсального запроса (в серверных БД для этого прекрасно подходит хранимка), выбирающего очередной номер как Select Max(DocNum)+1 from Table или для многопользовательского приложения из спец.таблицы номеров документов ?
В-третьих, при вводе документа "задним" числом можно опять-таки запросом вернуть "дырки" в последовательности значений поля DocNum
В-четвертых, что Вы будете делать, если в номере документа будет присутствовать нецифра, что, кстати, вполне допускается делопроизводством и встречается часто-густо, например, в бухгалтерии ?
В-пятых, как прикажете поступать в начале года, когда нумерация документов "сбрасывается" ? Или Вы пишете программы по принципу "главное - сдать, а там хоть трава не расти ?


 
Desdechado ©   (2006-09-19 11:20) [51]

MsGuns ©   (19.09.06 09:30) [46]
> Поподробнее про "сортированные" базы, пожалуйста
Anatoly Podgoretsky ©   (19.09.06 09:25) [45]
> Где ты видел сортированые базы? Что то новое в самолетостроении.
Про базы не скажу, а упорядоченное хранение в таблицах - есть.
Даже в тех же DBF была возможность командой SORT такими их сделать.
В Оракле есть index organized tables, которые физически хранятся упорядоченными по индексу.
Вроде, и в скуле такое читал.


 
SergP ©   (2006-09-19 12:07) [52]

> [50] MsGuns ©   (19.09.06 11:00)
>
> Вы вообще читаете то, что пишут другие ?


А Вы читаете, то что пишут другие?


> Или бегло просматриваете
> "по диагонали" ? Было сказано, что
>
> счетчики (читай ID) надо использовать стого по назначению
>
> а не пытаться соорудить из них какие-то там "нумера". Сколько
> раз Вам надо это объяснять ?


Я их вообще никак не использую. Имеется чужое ПО, которое их использует.


> В-пятых, как прикажете поступать в начале года, когда нумерация
> документов "сбрасывается" ? Или Вы пишете программы по принципу
> "главное - сдать, а там хоть трава не расти ?


С чего вы взяли что я пишу это? Написал же что используется готовое ПО.
Просто в некоторых случаях приходится вручную по базе лазить и подправлять, а для этого и приходится искать дыры выполняя запрос типа [2].
Или Вы сами не читаете, что другие пишут...


> [50] MsGuns ©   (19.09.06 11:00)
> >SergP ©   (19.09.06 10:28) [49]
> >Например:
> >Так там вычисление удаленных тем и сообщений иначе как
> по поиску дыр не получилось бы сделать.
>
> Если не получилось у Вас - это не значит, что нельзя вообще.


Ну хорошо...
были в таблице записи с ID:

1
2
3
4
5


в результате некоторых действий по удалению остались записи:

1
3
5


Ну и теперь нужно вычислить ID удаленных записей и передать изх клиенту, чтобы у него тоже они удалились (или отметка какая-то проставилась).
При этом не менять структуры базы (MySQL) на сервере, в.т.ч. не добавлять новых таблиц.
Подскажите как это сделать, без поиска "дыр". Буду Вам премного благодарен.


 
sniknik ©   (2006-09-19 12:18) [53]

> в результате некоторых действий по удалению остались записи:
> 1
> 3
> 5
в результате мер о которых выяснятся в этой ветке, после уделения (и этих мер) получим
1
2
3


и в общемто весь смысл "нотаций" (до вас) сводился к тому чтобы уговорить автора так не делать, ибо не имеет смысла (так то можно, тот же Johnmen както приводил ранее запрос на определение "дырки" "с и по"), но тут пришли вы и пытаетесь придать ветке какойто свой смысл... причем приводя примеры которые на сделаной перезаписи "дыр" попросту не заработают.

p.s. без обид но впечатление, что действительно "по верхушкам" читал...


 
sniknik ©   (2006-09-19 12:27) [54]

в той постановке задачи [52] -> последний абзац, возможно и есть смысл, но это немного не та интерпретация что в основе вопроса.

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


 
SergP ©   (2006-09-19 12:36) [55]

> [53] sniknik ©   (19.09.06 12:18)
> и в общемто весь смысл "нотаций" (до вас) сводился к тому
> чтобы уговорить автора так не делать, ибо не имеет смысла
> ..., но тут пришли вы и пытаетесь
> придать ветке какойто свой смысл... причем приводя примеры
> которые на сделаной перезаписи "дыр" попросту не заработают.
>


Собственно говоря если все делать как положено, то в "затыкании дыр" я смысла не вижу.
Но вероятно я не то сообщение процитировал.
В действительности я отвечал на:


> [5] Desdechado ©   (16.09.06 12:27)
> Какой смысл в поиске дыр?


т.е. что касалось смысла "поиска дыр" а не их "затыкания"

> (так то можно, тот же Johnmen както приводил ранее запрос
> на определение "дырки" "с и по")

помню такое... это было года 3 назад. Причем вопрос о поиске дыр задавал именно я.


 
SPACE!!   (2006-09-19 17:09) [56]

> нет механизмов вроде автоинкремента для автоматизации и контроля работы с ID

Как писал MsGuns  : Select Max(DocNum)+1 from Table .  Ну и конешно сделать поле уникальным.


> Ну и теперь нужно вычислить ID удаленных записей и передать
> изх клиенту, чтобы у него тоже они удалились (или отметка
> какая-то проставилась).

Особо подчеркну слово клиент , если имеется в виду клиентское приложение которое работает непосредственно с твоим MySQL сервером,
то делаешь пишешь просто сервер который работает как передатчик SQL
запросов, подчеркиваешь как-то запрос Delete типа :

 SendToServer(SQL : string;delete : boolean);

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

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


 
Desdechado ©   (2006-09-19 17:55) [57]

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


 
SPACE!!   (2006-09-19 23:09) [58]


> ну-ну, а если клиент в это время выключен был, а потом решил-
> таки подключиться к форуму и обновить список веток в локальной
> копии?

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



Страницы: 1 2 вся ветка

Форум: "Начинающим";
Текущий архив: 2006.10.08;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.58 MB
Время: 0.049 c
3-1154942212
cosmos
2006-08-07 13:16
2006.10.08
не проходит запрос INSERT INTO в ACCESS


3-1154572849
VitalikS
2006-08-03 06:40
2006.10.08
Трансформация таблицы


15-1158440180
Германн
2006-09-17 00:56
2006.10.08
Самопроизвольно перегружается компьютер WinXP


15-1158580296
гастрит
2006-09-18 15:51
2006.10.08
форма


15-1157627753
Chort
2006-09-07 15:15
2006.10.08
13 сентября - День компьютерщика и программиста





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский