Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как опеспечить уникальность записи в VARCHAR(255)? [D7, IB6.x]

Страницы: < 1 2 3
Shama_n © (2004-06-29 18:23:00)
База данных InterBase примерно на 15000 записей и в поле типа VARCHAR(255) нужно недопустить дублирования одинаковых записей. Данные в БД добавляются очень часто и выполнение проверки уникальности каждого значения методами поиска. Подскажите максимально быстрый метод обеспечения уникальности значения?

TohaNik (2004-06-29 19:53:00) [41]
Vlad © (29.06.04 19:32) [8]
>Такие значения нужно позволять вводить, просто потом делать ручную выверку базы, это стандартная схема.

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

P.S. Видел старую клипперовкую программу по учету мат. ценностей
так вот кроме этой стандартной для клиппера ф-и при вводе "Оце" - возвращалось "ацетон" ну смысл понятен.
Вероятно использовался некий алгоритм перестановок в хэш таблицах с доп условиями. ??? Вообще интересует наиболее удобная и понятная для пользователя схема.

Vlad (2004-06-29 19:53:00) [42]

> Shama_n © (29.06.04 19:35) [9]

> Создание уникального индекса в моем случае ничего не решает

Как это не решает ? По крайней мере уникальный индекс автоматически обеспечивает уникальность поля. Разве не это требовалось ?
Другое дело, что IB вроде-бы не позволяет создавать индексы по varchar полям длиннее 80 с чем-то символов, если они в русской кодировке.

Shama_n (2004-06-29 19:35:00) [43]
Создание уникального индекса в моем случае ничего не решает. Обращение к БД происходит так часто что что поиск в даже по индексному полю в БД с числом записей свыше 4000 сильно тормозит сервер. У меня есть мысли как обеспечить мгновенный поиск в базе данных любого размера просто не хотел изобретать велосипед дважды, но кажется придется. Напишу как это сделать когда приеду домой. Часа через 2 . Может кто за это время меня опередит? ;)

Vlad (2004-06-29 19:32:00) [44]

> TohaNik © (29.06.04 19:20) [6]

Если ты имеешь ввиду чтобы пользователь не ввел к примеру так:
'Иванов И И' и 'Иванов И.И.' ?
ИМХО, подобные "дубли" ты никак не отследишь.
Такие значения нужно позволять вводить, просто потом делать ручную выверку базы, это стандартная схема.

Vlad (2004-06-29 19:26:00) [45]

> TohaNik © (29.06.04 19:20) [6]

Как у кого ? У меня на Оракле индекс уникальный ставится в таком случае :-)))

TohaNik (2004-06-29 19:20:00) [46]
Оч. скромное ИМХО.

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

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

Vlad (2004-06-29 19:15:00) [47]

> Shama_n © (29.06.04 19:05) [4]

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

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

Shama_n (2004-06-29 19:05:00) [48]
>Vlad
>Это что, шутка ? Сумма кодов всех символов это не даст уникального значения.
>'AB' и 'BA' даст одно и тоже число, и что ты дальше будешь делать ?
Конечно не даст :) После нахождения записи по индексному полю нужно сделать проверку по VARCHAR что нашли именно нужную запись и если запись не та что искали то ищем следующую запись и так или пока не найдем то что искали или пока таблица не закончится. В итоге такой алгоритм всеравно гораздо быстрей чем обычный поиск

Vlad (2004-06-29 18:55:00) [49]

> Shama_n © (29.06.04 18:38) [2]

> существует индексное поле integer в которое заносится сумма
> кодов всех бувк в VARCHAR и перед поиском строки сначала
> суммируются все коды букв и затем производится поиск по
> индексному полю integer

Это что, шутка ? Сумма кодов всех символов это не даст уникального значения.
'AB' и 'BA' даст одно и тоже число, и что ты дальше будешь делать ?

Я так понимаю, поле в русской кодировке и уникальный индекс ты по нему создать не можешь из-за его длины (255) ?

Shama_n (2004-06-29 18:38:00) [50]
Сомневаюсь что самое оно...
Допустим сейчас в моей программе реализован не прямой поиск по VARCHAR а существует индексное поле integer в которое заносится сумма кодов всех бувк в VARCHAR и перед поиском строки сначала суммируются все коды букв и затем производится поиск по индексному полю integer что гораздо быстрей. Но когда БД увеличивается до 3000-4000 тыс записей и этот метот оказывается бесполезным. У меня есть еще мысли как все можно оптимизировать но возможно я изобретаю велосипед дважды и хочется услышать мнение мастеров :)

Соловьев (2004-06-29 18:26:00) [51]

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

для такого поля самое оно...

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »