![]() |
Подскажите.. Paradox
Года 2 назад делал курсач по программированию с базами данных.. Сейчас понял, что все совершенно забыл!.. Так тчо не бейте сильно...
Так вот! У меня следующая проблема. Имеется база данных клиентов, в которой ведется поиск по введенным значениям. По каким именно полям - узнается после проверки, какие Edit'ы заполнены. Про кривость кода: пока сделал, чтобы хоть работало. Потом буду "шлефовать". Критику (с конкретными предложениями) принимаю! Код:
procedure client_from_db(var cldb: clientzap);Код:
With Form1.Query3 do |
Я в таких случаях делаю следующее:
1. обязательно вывожу текст sql запроса перед его передачей в БД 2. проверяю его в какой-нить тулзе, чтобы увидеть ошибки выдаваемые самой БД, если она такое умеет (mssql, например, можно прямо в enterprise manager попытаться выполнить запрос) Кстати, чем проверять на пустоту каждое окошко ввода, не лучше ли ставить флаги по событию редактирования объекта и потом по установленным флагам собирать запрос? |
1. Решение проблемы нашел :)) Надо было делать Open, а не ExecSQL.
2. Это тоже вариант. Но мне сейчас главное сделать чтобы все требуемые операции с БД проходили нормально. Все остальное возможно переделаю :cool: Все равно спасибо! ;) И еще вопросы! 1.Как узнать сколько всего записей в таблице? 2.Гдето кажется читал, что, для того чтобы ускорить поиск поиск в БД надо сделать поля индексируемыми. Если не так, то как ускорить поиск? Можно ли все поля проиндексировать? 3.Какие еще есть команды SQL.. ну типа First - встать на первую запись, Next - следуюущая. Как узнать сколько всего записей в таблице? МОжно ли узнать сколько в таблице записей подходящих "по маске"? Где можно обо всем жтом поподробнее почитать? На русском желательно ;) Спасибо :) |
SteFF
Сейчас книжек по программированию БД в Delphi предостаточно, выкладывались и у нас на форуме. Методы First/Next - это не к SQL, а к классу TDataSet (родитель для TTable и TQuery). Есть свойство RecordCount для определения количества записей. Индексировать нужно только те поля, по которым ты чаще всего делаешь поиск, т.е. пишешь в SELECT условие типа WHERE ID = ... Вот тогда ID стоит проиндексировать. Все индексировать не имеет смысла. Индексы дают выигрыш при выборках данных. Но есть и обратная сторона - при добавлении/изменении записей индексы вынуждены перестраиваться. Так что оценивай как часто будут у тебя данные меняться, или больше будут только выбираться. |
Цитата:
|
У меня будет много полей.. имена, фамилии, адреса, телефоны, е-mail и еще много полей, в которых будут небольшие числа. Поиск будет происходить по: имя, фамилия, телефоны(3), емейл, адрес. Значит лучше будет сделать эти поля индексируемыми?
Слышал что в парадоксе индексы слетают.. чем это грозит? Полной потерей данных? :eek: Или их можно бдует восстановить? :idontnow: :) |
Цитата:
Цитата:
На случай "слёта" индексов обычно предусматривается процедура переиндексации. |
Индекс имеет смысл делать если после фильтрации по нему останется не более 5-10%. И не стоит делать более 5-7 индексов на таблицу. Так же разумно бывает делать составные индексы.
|
Цитата:
|
Как искать подстроку в строке? Например: мне надо найти фамилию человека в БД.. а я помнб только пару букв его фамилии? Как можно это реализовать? :confused: И возможно ли?
|
Цитата:
При этом обрати еще внимание на регистр. Возможно лучше будет написать что-то типа ...WHERE UPPER(SecondName) LIKE '%БУКВЫ%' Также отмечу, что при таком поиске с неизвестной первой буквой, даже MS SQL Server не использует индес по полю, а сканирует таблицу. Так что и Paradox вряд ли будет. Т.е. поиск по первым буквам должен теоретически быть эффективнее чем поиск по вхождению, если поле проиндексировано. |
А как тогда мне в запросе указать, что '%буквы%' это как раз первые буквы слова (строки в БД), а не просто подстрока? :confused:
|
Для поиска по первым буквам пиши 'буквы%'. Тут % - это просто маска, означает произвольное количество каких-либо символов.
|
А. все. Теперь понял.
Спасибо! ;) |
| Часовой пояс GMT +4, время: 15:06. |
Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.