Order By почему бы не PK просто вместо created_at?

[Vano]

Как думаете никаких приколов не будет, если писать ORDER BY $pk вмесето created_at? При идеальном условии что PK только аутоинкрементом будет создаватся.

 

[AnrDaemon]

Чё?

 

[c0dex]

Почему создал в теории? Где теория, и где вообще программирование?

 

[Vano]

По первичному ключу (автоинкрементном) сортировать лучше чем по дате создания? Явно же быстрее будет выборка

 

[AnrDaemon]

Какая нафиг разница, если на поле индекс?
Сортируй так, как тебе данные удобно доставать. Не морочь голову ни себе, ни людям.

 

[Vano]

Разница в том, что быстрее работает.

 

[AnrDaemon]

На сколько от этого ускоряется работа всего приложения?

 

[Vano]

2к записей. По полю даты 0.023с, по первичному ключу 0.017с. Поставил индекс на дату стало 0.022с

 

[Vano]

Значит быстрее, вопрос только в том, не всплывет ли где проблема из-за такого ордера.

 

[AnrDaemon]

Я задал другой вопрос. На сколько (в процентах) меняется скорость выполнения ВСЕГО ПРИЛОЖЕНИЯ?

 

[c0dex]

Мне кажется, что если ты ставишь тот или иной ордер - ты должен САМ отдавать себе отчет в том, что может "что-то вылезти". Другой вопрос что created_date и первичный ключ могут в теории идти не нога в ногу.

 

[Vano]

Эй приятель, здесь я задаю вопросы. )) та не знаю, трудно сказать, наверное на 0.5% максимум

 

[Vano]

вопрос что created_date и первичный ключ могут в теории идти не нога в ногу.

ну да...
В общем пишите дети ORDER BY date, будете здоровы.

 

[AnrDaemon]

Эй приятель, здесь я задаю вопросы. )) та не знаю, трудно сказать, наверное на 0.5% максимум

Стоят эти 0,5% твоих терзаний сейчас? При том, что всё работвет корректно.
Я понимаю, когда у человека запрос в 50 раз медленнее выполняется. Но это явно не твой случай.

 

[c0dex]

@AnrDaemon да он сам не понимает, что если у него каким-то магическим образом на created_date может влиять юзер - то да, получить выборку чисто по дале и верно - можно только сортировав по полю с датой. А если же они идут параллельно с PK, то сортировка по PK приоритетней.

 

[Vano]

Ты не прав обо мне. Я понимаю что разными могут быть сорты ПК и Даты. Я ж написал в начале, если брать идеальный вариант что ПК назначается только по порядку. А дата создания ... я так привык, что она неприкосновенна и нужна для того, чтобы явно знать когда создалась запись в БД, для пользователя создаю какое-нибудь другое поле.

 

[hell0w0rd]

А мне вот кстати интересно про soft-delete. Нарыл тесты, показывающие, что индекс вообще на deleted_at по хорошему не нужен. Что за фигня?
http://stackoverflow.com/questions/26525068/does-laravels-soft-delete-need-index-on-mysql/26530488#26530488

 

[флоппик]

Да, так и есть. Туту явный пример с асимметрией значений ключей, что дает низкую селективность по оценке БД (обратная зависимость от кардинальности, на основе селективности БД принимает решение о использовании индекса), но в реальности фулл-скан в такой ситуации выгодней и индекс скорее всего, будет вредить.

 

[hell0w0rd]

Да, так и есть. Туту явный пример с асимметрией значений ключей, что дает низкую селективность по оценке БД (обратная зависимость от кардинальности, на основе селективности БД принимает решение о использовании индекса), но в реальности фулл-скан в такой ситуации выгодней и индекс скорее всего, будет вредить.

А для построения частичных индексов постгресом тоже не влияет? (create index ... where deleted_at is null)

 

[antson]

про перевод времени помним ?
то оно есть,то его нет, а функция все толще и толще из-за исключений.