Как узнать, какие запросы грузят базу данных?

Статус
В этой теме нельзя размещать новые ответы.
Ну а чем datetime не уникальное поле? Сколько работал с фоурмами, сайтми - вероятность появления двух событий в одну секунду меньше 1 на 1000. Насчет индексов да, что-то я спутил, согласен
 
Ну а чем datetime не уникальное поле? Сколько работал с фоурмами, сайтми - вероятность появления двух событий в одну секунду меньше 1 на 1000. Насчет индексов да, что-то я спутил, согласен
как правило уникальным ставят интеджер значение и всякие выборки и джоины и внешние ключи оптимизированы под такой тип, да и проще вообще следить и проверять значения.
при том, что INT имеет 4 байта, DATETIME - 8. Лучше уж DATETIME заменить на BIGINT, который тоже 8 байт.
 
Это имеет значение только при очень большимх базах, разве не так?
да
скорее всего для поиска и джоинов оно будет конвертить дату в таймстамп и потом сравнивать, всё таки лучше брать сразу интежэер значения как первичные ключи, чтоб не было нюансов в будущем
 
можно использовать утилиту mysql: explain.
она объясняет на сколько полезный ключь и используется ли он вообще.

английская инструкция, но уверен должно быть и на ру
Для просмотра ссылки Войди или Зарегистрируйся
 
как правило уникальным ставят интеджер значение и всякие выборки и джоины и внешние ключи оптимизированы под такой тип, да и проще вообще следить и проверять значения.
при том, что INT имеет 4 байта, DATETIME - 8. Лучше уж DATETIME заменить на BIGINT, который тоже 8 байт.

Сейчас почти везде ставят guid, смотрю. Очень много встречал, даже сам начал так делать :) Гарантирует, что не будет двух одинаковых ключей в базе. Т.е. 10000 в одной и 10000 в другой таблице, например, следовательно, можно однозначно идентифицировать не только строку но и таблицу.
 
Сейчас почти везде ставят guid, смотрю
это как в микрософт (ms sql) и тогда было кучу публицаций почему это круто, правильно и так далее. разницы чесно говоря не видел, кроме того, что дико неудобно стало дебагать изменения даных и тестировать функционал, от гуидов голова кругом шла, вместо того, что было скажем 666 - стала невообразимо длинная хрень
 
это как в микрософт (ms sql) и тогда было кучу публицаций почему это круто, правильно и так далее. разницы чесно говоря не видел, кроме того, что дико неудобно стало дебагать изменения даных и тестировать функционал, от гуидов голова кругом шла, вместо того, что было скажем 666 - стала невообразимо длинная хрень

Да, я тоже поначалу так относился, но, теперь даже на свои мелкие проекты везде GUID ставлю :)

С точки зрения отладки данных - ну, смотришь на первые или последние несколько символов, обычно, хватает, чтобы понять, оно или не оно, ну да, конечно, с ИД проще, например, юзер айди 25 а сейчас вадалоыао-23408вадывло-ывадвлдыа-ыдвалов.

На сайтах тоже, в некоторых отношениях лучше числовые айди, ссылки вида /article=2049q3707ddf-sdfdsf98-dfdsfdsf-dsfdff совсем пугают :( Но тут я стараюсь не выводить в урлы вообще никаких айди...

Ну, основная крутость - ключ - сам по себе уникальный идентификатор записи, а не как в модели числовых айди, когда это обязательно таблица / ключ.
 
На сайтах тоже, в некоторых отношениях лучше числовые айди, ссылки вида /article=2049q3707ddf-sdfdsf98-dfdsfdsf-dsfdff совсем пугают :( Но тут я стараюсь не выводить в урлы вообще никаких айди...

Для СЕО такие урлы естественно плохо подходят, но при этом имеют одно большое преимущество - никто не спарсит информацию с сайта, задав в цикле перебор страниц. Раньше я как-то не не задумывался о GUID, но видимо стоит попробовать
 
Для СЕО такие урлы естественно плохо подходят, но при этом имеют одно большое преимущество - никто не спарсит информацию с сайта, задав в цикле перебор страниц. Раньше я как-то не не задумывался о GUID, но видимо стоит попробовать
информацию в любом случае можно спаристь, будь то guid либо простой id, тут уже зависит от фронтенда и сайтмапа
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху