sergey_w Сообщение 22/04/2007 00:24 Копия темы
Помогите с sql запросом от хостера где находиться сайт пришло сообщение:
«select * from messages where komu = 'lennon_2006' && ot = 'leila30' с аккаунта огромная нагрузка»
Не подскажите как оптимизировать

Andrey_v Сообщение 22/04/2007 04:31 Копия темы

EXEtrimALL Сообщение 22/04/2007 05:56 Копия темы
Хороший, видать, хостер. РБК говорит высокая нагрузка – и все. Ни где, ни когда – ничего...

EXEtrimALL Сообщение 22/04/2007 05:57 Копия темы
+1
вообще везде лучше свего использовать ID, кроме редких случаев.

Adroit Сообщение 22/04/2007 08:38 Копия темы
Не факт...
Хотя и сам в каждой главной таблице поле id присобачиваю, но считаю эт ненужным, т.к. скорость запроса одна и таже, что по int что по char, если поле ключевое или индексное

Adroit Сообщение 22/04/2007 08:39 Копия темы
Убедитесь что поля komu и ot – есть составной неуникальный индекс, если нет – то создайте его и будет вам щасте

InsiderJunk Сообщение 22/04/2007 10:04 Копия темы
Абсолютно согласен, ID как ключевое уникальное поле просто необходимо везде! Читайте теорию БД.
А чтобы оптимизировать запрос по CHAR необходимо действительно построить индекс на этих полях, тогда в недрах СУБД создастся доп табличка с ХЭШами от обойих значений, и соответственно поиск будет осуществлен по хэш функциям что гораздо быстрее.
А вообще правильно работать уникальными идентификаторами.

EXEtrimALL Сообщение 22/04/2007 10:28 Копия темы
Лично я не использую id только в небольших таблицах с часто меняющимися значениями, например таблица с сессиями.

Adroit Сообщение 22/04/2007 12:27 Копия темы
Абсолютно согласен, ID как ключевое уникальное поле просто необходимо везде! Читайте теорию БД.
_________________
А зачем тогда составные ключи? )) Почитайте хотя б _методичку_ по ТПБД )) нет там никаких ID

ID уместно только когда индекс строится бинарным деревом ) Если он строится хэшем – до лампочки, хоть char хоть int хоть guid

InsiderJunk Сообщение 22/04/2007 16:30 Копия темы
Если на составных ключах Вы и выезжаете, то это хорошо.
Однако представьте себе большую БД очень большую. Сотни-тысяки таблиц, куча процедур и т.п. Сотни разаботчиков. (так я и работаю примерно) Так вотВам говорят проблема с записью по ключу поле1=занчение1, поле2= значение2 и т.п., либо Вам г7оворят, ID такой то – разберись, где недостатки, я смотрю, и вижу классификатор сокращен администратором а вот ID из классификатора в этой записи как раз из сокращенных. Тут прогсто пишу реквизицию админу БД и все! Все становится проще, а вот при небольших пректах пользуйтесь чем хотите, но начнете масштабировать и тп. и загнетесь однозначно.

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

PS^ насчет хэшей и составных ключей по которым строится хеш абсолютно согласен, но это зачастую необходимо для оптимизации запросов, мы пару раз снижали таким образом время выполнения с 20 минут до 10 секунд, но правда по всей логике составной индекс там не нужен. Так что бывают ситуации где нужно действовать и по обстоятельствам
Так проще работать а памяти и дискового пространства оно почти не жрет, а вот оперативность повышает серьезно, особенно с ростом проекта.

Adroit Сообщение 22/04/2007 16:55 Копия темы
Изначально проектируемая БД должна быть МАСШТАБИРУЕМА, это и так понятно, другое дело, что не все следуют этом правилу...

По поводу таблиц – связок – не согласен... какую информацию это ID вообще может нести? Зачем оно? Ключ? Ну да – ключ, а зачем? Зачем мы можем определить запись в отношении по полю, значение которого мы никогда не знаем? )

ПыСы: Я не противник ID, говорю же сам использую, но считаю это скорее «вредной привычкой», и стараюсь потихоньку от нее избавляться (по мере возможности). Естественно, если составной ключ приходится городить более чем из 3-4 полей – проще использовать ID, или если с этим составным ключем ничего не связано либо связать неудобно

Например зачем в таблице TUsers поля FId и FLogin? Избыточность это. Все делают ID – ключем, а Login уникальным индексом... Просто ТАК ВСЕ привыкли ) Но ID по большому счету тут вообще не нужен, согласитесь?

Когда я говорю о целесообразности использования составного ключа я имею ввиду например:

Есть n-объектов, каждый из них может находиться на одной из координат в пространстве (2 объекта на обной координате быть не могут)
Координаты определяются X,Y,Z.
И зачем тут ID?

EXEtrimALL Сообщение 22/04/2007 17:28 Копия темы
деваааачки не ссоооорьтесь! :)
похоже, это примерно тот же спор, что и дивы против таблиц :)
каждый делает так как ему болье нравится, удобнее, как он привык. ну и пусть продолжает.

EXEtrimALL Сообщение 22/04/2007 17:30 Копия темы
кстати, по поводу логина. могут возникнуть проблемы с передачей логина в SQL при использовании спецсимволов...

Adroit Сообщение 22/04/2007 23:25 Копия темы
По умолчанию их запрещают ;) только латиница, цифры и подчеркивание )

gogolev Сообщение 23/04/2007 12:38 Копия темы
По умолчанию хорошим тоном считается использование параметризованных запросов.

gogolev Сообщение 23/04/2007 12:59 Копия темы
Ерунду говорите, товарищ. Синтетический первичный ключ всяко лучше первичного ключа с бизнес-значением. Вот захочет в вашем варианте пользователь сменить себе логин. Как будете в таком случае поступать? Менять логин во всех связанных таблицах?

nikitian Сообщение 26/04/2007 20:20 Копия темы
Можно url-кодировать при записи в базу. Тогда из спецсимволов только %. Это не самый изящный способ, но работает, особенно хорошо с кирилицей

nikitian Сообщение 26/04/2007 20:22 Копия темы
Не выбирайте все поля, а только нужные. Имхо, komu & ot можно уже не выбирать :)
Можно лимит поставить, если много полей выбираются и грузят сервант...