Была у меня программа, которая довольно сносно работала с текстовыми базами (самодельными)

пример:

{art}ARTIST
{alb}ALBUM
{gen}GENRE
.........
........
.......


Была у меня текстовая БД в 5 mb, я ее полностю грузил в оперативку , а там уже работал с ней.

Решил перейти на реляционные БД.

За месяц переделал прогу с текстовых БД на MSSQL.

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


Разве так может быть??????????????????????


P.S.
Произвожу поиск по тексту. (%ANY_TEXT%)

Раслабься, так и должно быть!!!!
Всё, что загружено в оперативку, обрабатывается быстрее, чем то что храниться в БД.

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

4 Artemon БД ведь у тебя лежит на винте. Посмотри скорость доступа к винту и скорость доступа к оперативке и сразу всё поймешь.

Жестоко.

Хм... Возможно дело в неправильной оптимизации. MS SQL Server достаточно по умному кэширует данные и оставляет запрашиваемые данные в оперативке. Лучше приведи примеры запросов которые тормозят и структуру таблиц на которых они проходят.


PS. Базы данных действительно не дадут выигрыша в скорости на небольших массивах данных, потому как неизбежны накладные расходы в виде ретрансляции потоков данных из одной программы в другую, многоступенчатые преобразования: программа-драйверБД-сервер-данные, компилляция запросов и т.д. Но у баз данных есть неоспоримые преимущества - они дают значительное увеличение производительности на больших масивах данных или при многопользовательском использовании, делают системы легко расширяемыми и дают существенные удобства в манипулировании данными.

Вот у меня какой самый тормозной запрос




P.S.
В каждой таблице не больше 40000 строк

Мдя... Ты делаешь декартово произведение... Реально ищется не через 40000, а через 40000*На ARTISTS * на GENRES * SONGS, т.е. реально сервер лопатит десятки миллионов записей.

Чтобы сделать это по человечески наду применить Join (Inner или Outer в зависимости от задачи)

Что-то вроде:


Кроме того надо поставить индекс на поле SONG, желательно кластерный

Если это не поможет, тогда надо будет ещё поработать над оптимизацией.

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

Vit, ты не прав. Artemon использовал inner join по старой системе, так что у него не получилось декартово произведение.

Вроде как то, что он использовал - это "Cross Join" по старой системе, но я могу ошибаться, сейчас посмотрю как MS SQL Server меняет план выполнения запроса в этом стиле...
Добавлено @ 16:03
Ага, ты прав... Inner Join получается... Тогда, Artemon присылай базу данных, попробую покрутить у себя и подумать как сделать её побыстрее... В любом случае на 40K записей практически любые запросы должны выполняться практически мгновенно...

Vit, огромное спасибо, но нет возможности выслать базу.

Тогда смотри сам в Query Analyser чего твоя квери делает и какая операция жрёт время. Индексы ставить не пробовал?

На вскидку нужны индексы по следующим полям

ALBUMS.ID_ARTIST =
ARTISTS.ID_ARTIST
ARTISTS.ID_GENRE
GENRES.ID_GENRE
ALBUMS.ID_ALBUM
SONGS.ID_ALBUM
SONG

Желательно кластерный индекс по полю SONG

А что значит кластерный?

В селекте участвует 4 таблицы, если в них нет индексов то происходит довольно ощутимое сканирование таблиц.
Желательно, а то и обязательно индексы по полям:
ID_ALBUM в таблицах ALBUMS и SONGS
ID_ARTIST в таблицах ALBUMS и ARTISTS
ID_GENRE в таблицах ARTISTS и GENRES