Мастера 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) нужно недопустить дублирования одинаковых записей. Данные в БД добавляются очень часто и выполнение проверки уникальности каждого значения методами поиска. Подскажите максимально быстрый метод обеспечения уникальности значения?

Vlad (2004-06-30 12:47:00) [21]

> Shama_n © (30.06.04 10:57) [29]

> Думаю бинарный и используется но работает он только с отсортированым
> набором данных

Неверное предположение. Бинарный метод работает с любым, хоть отсортированным хоть неотсортированным набором данных. Главное чтобы индекс был по тому полю, которому отбираешь записи.

> InterBase производит сортировку после каждой новой записи?
>

Ну не причем тут сортировка. После вставки каждой новой записи (равно как и при удалении и изменении) он просто изменяет соотв. информацию в индексе.

Danilka (2004-06-30 11:48:00) [22]
[29] Shama_n © (30.06.04 10:57)
> Я новичек в БД и поправьте меня пожалуйста если я где-то
> ошибаюсь

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

Shama_n (2004-06-30 10:57:00) [23]
>Какая разница, сколько операций. Главное - время. Какое тебя удовлетворит?
Сейчас уходит по 3-4 часа времени и скорость падает прогрессирующе относительно размера базы. Думаю когда база вырастет в 3-4 раза сверка будет занимать дней 5 :(

>Сортировка к хранению никакого отношения не имеет...:)
К хранению согласен а к поиску в наборе данных тоже не имеет?

>>поиск в ней будет производится бинарным методом
>А при поиске по индексированному полю думаешь используются более слабые алгоритмы ? :)
Думаю бинарный и используется но работает он только с отсортированым набором данных. InterBase производит сортировку после каждой новой записи? Если так и есть то возможно только в этом причина прогрессирующего падения скорости. Мой способ с 2 таблицами реализовывает сортировку после каждых 200 записей.

Я новичек в БД и поправьте меня пожалуйста если я где-то ошибаюсь

Алхимик (2004-06-30 01:05:00) [24]
Сдаётся мне что про нормализацию Вы не слышали.
Ключ на основе наименования товара (естественный ключ ЕК) - не самое лучшее решение.
Рекомендую -
Анатолий Тенцер
"Естественные ключи против искусственных ключей"
http://www.akzhan.midi.ru/devcorner/articles/NaturalKeysVersusAtrificialKeysByTentser.html

Johnmen (2004-06-29 23:13:00) [25]
>Shama_n © (29.06.04 21:49) [26]

>Если перемножить то получим немаленькое кол-во необходимых операций

Какая разница, сколько операций. Главное - время. Какое тебя удовлетворит ?

>В одной будут находится отсортированые ...

Сортировка к хранению никакого отношения не имеет...:)

>поиск в ней будет производится бинарным методом

А при поиске по индексированному полю думаешь используются более слабые алгоритмы ? :)

>>> опять при сортировку.......

Она здесь ну абсолютно непричём. См.выше.

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

Shama_n (2004-06-29 21:49:00) [26]
Mim1>В поле хранится наименование товара. В основном больше 70 символов

Создание одного только уникального, точней полууникального :), индекса не решает проблемму так как в базу из 15000 записей необходимо загнать только недублирующиеся в БД значения примерно из 7000 записей. Тоесть для всего списка из 7000 нужно сделать сверку с базой данных. Если перемножить то получим немаленькое кол-во необходимых операций :( Единственное до чего додумался это создать 2 таблицы В одной будут находится отсортированые по индексу записи и поиск в ней будет производится бинарным методом. Во вторую таблицу будут попадать только новые и еще неотсортированые записи в ней придется искать стандартным способом. Когда размер второй таблицы превысит скажем 200 записей, все записи нужно будет перенести в первую таблицу и произвести там повторную сортировку

Vlad (2004-06-29 21:49:00) [27]

> Fay © (29.06.04 21:47) [24]

> Да хоть бы

:-)))

Fay (2004-06-29 21:47:00) [28]
Да хоть бы и Oracle.

Vlad (2004-06-29 21:46:00) [29]

> Fay © (29.06.04 21:39) [22]

ага, Оракл например :-)

Fay (2004-06-29 21:39:00) [30]
Очень неплохо помогает выбор другой СУБД. 8)

Sergey Masloff (2004-06-29 21:37:00) [31]
Vlad © (29.06.04 21:15) [20]
Кстати я как всегда наискосок прочитал первое сообщение и все. Про хэш ты почти сразу написал - я просто не видел ;-)

Vlad (2004-06-29 21:15:00) [32]

> Mim1 © (29.06.04 21:14) [19]

И как дальше эти части индексировать ?

Mim1 (2004-06-29 21:14:00) [33]

> Shama_n © (29.06.04 18:23)

Скажите а что хранится в этом поле? Нельзя ли эти 255 разделить на части?

TohaNik (2004-06-29 20:54:00) [34]
Vlad © (29.06.04 20:36) [15]
Завтра посмотрю.
Sergey Masloff (29.06.04 20:39) [16]
И про MD5 поищу, ато не осведомлен%)

Vlad (2004-06-29 20:51:00) [35]

> Sergey Masloff (29.06.04 20:39) [16]

Я боюсь что не будет особой разницы, хранить хеш MD5 (16 байт в числовом или 32 в HEX формате) или же саму строчку VARCHAR.
Во всяком случае при таком небольшом количестве записей как у автора, разницу в скорости врядли почувствуешь

Sergey Masloff (2004-06-29 20:39:00) [36]
Считай хэш для строки. Какой-нибудь MD5 я думаю обеспечит вполне достаточную уникальность.

Vlad (2004-06-29 20:36:00) [37]

> Хотелось-бы ссылки увидеть;)

На сколько я знаю, для этого используются нейронные сети
Хороших ссылок на эту тему к сож. не знаю, но вот первое что в Яндексе попалось
http://ermak.cs.nstu.ru/~avg/ARTICLES/Ngtu-99.htm

TohaNik (2004-06-29 20:26:00) [38]
> А если просто пытаться разбирать строчку на части, то это
> надо сложную чуть ли не интелликтуальную систему писать
>

Ну почему - разбить фразу на словапри наличии пробелов ест-но не сложно.
Можно в цикле потом и каждый символ видеть как любой-делая select- и вываливать это в какой-нибудь List исключая одинаковые id Но ИМХО это криво и без логики и медленно наверно(не пробовал). А интеллектуальная система- ну смотря до какого уровня соответствий и требований....
Хотелось-бы ссылки увидеть;)

TohaNik (2004-06-29 20:25:00) [39]
> А если просто пытаться разбирать строчку на части, то это
> надо сложную чуть ли не интелликтуальную систему писать
>

Ну почему - разбить фразу на словапри наличии пробелов ест-но не сложно.
Можно в цикле потом и каждый символ видеть как любой-делая select- и вываливать это в какой-нибудь List исключая одинаковые id Но ИМХО это криво и без логики и медленно наверно(не пробовал). А интеллектуальная система- ну смотря до какого уровня соответствий и требований....
Хотелось-бы ссылки увидеть;)

Vlad (2004-06-29 19:58:00) [40]

> TohaNik © (29.06.04 19:53) [11]

ИМХО, наиболее понятная (и полезная для системы) схема - это жесткие маски ввода.
Если у тебя поле содержит ФИО то пользователь должен вводить его в три разных Edit'а. Причем каждый из них должен пропускать только определенный набор символов, и т.п.
А если просто пытаться разбирать строчку на части, то это надо сложную чуть ли не интелликтуальную систему писать :-)

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

Наверх

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