Структура , вес, оптимальность, взаимосвязь.

[yok]

Структура , вес, оптимальность, взаимосвязь.

Делаю регистрацию, поэтому мускул разбираю, и не дают мне покоя некоторые вопросы.

И вот допустим , для регистрации допустим всего одна таблица. ОДНА. ИМенно.

И вот первый вопрос 1, если таблица одна, и выборка идет по логину, зачем нам индекс, и само поле вообщето id INT,
мало того, что оно есть вес, плюс еще и индекс автоматически на нем формируется.
Почему не назначить индекс по логину. Разумней , оптимальней.

2 вопрос. Поле date 3 байта, поле timestamp 4байта. Вобще ресурсозатраты на запрос вероятно заточенный под INTERVAL, от timestamp , меньше чем сравнение с date.

2 вопрос это как бы познавательный. А вот 1 почему то даже оправданный, лишнее поле int , и не необходимое, по которому формируется индекс. НЕРАЗУМНО ПОЛУЧАЕТСЯ. причем учтите из подхода одна таблица.

Мысли есть какие??

 

[c0dex]

Преждевременная оптимизация не есть хорошо)

 

[yok]

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

 

[Adelf]

yok
Да потому что другие вещи тормозят у людей, поэтому и не поднимается.
Есть у моего народа поговорка - не чеши там, где не чешется. Очень правильная

 

[yok]

Adelf почему чешу?

Разбирался с регулярными, пока JEF Friedlа не перечитал, проверки не создал оптимальные. Хотя очень много предложений , рекомендаций. Надо было только попыхтеть и оптимальное будет. И оно было сделано. А в нете не удовлетворяло. И даже из учебников.
Да, так уже и забыл пособие, а наработки использую, но знаю что ОК.
Поэтому и тут пытаюсь разобраться получше.

Это как начинать на пк, надо научиться слепым десятипальцевым, а иначе ерунда будет.

Вот ты прочитал мои два вопроса и конкретно бы сказал свое мнение по каждому.
Замечание c0dex, преждевременная оптимизация, правильно,хотя хотелось бы и по вопросам интересный ответ.

Твое замечание, тоже правильно, но опять же хотелось бы по вопросам.

 

[c0dex]

yok
Поле id тебе нужно будет после регистрации (Если ты не разделяешь пользователей на 2 таблицы, тех кто хочет регнуться и тех, кто уже подтвердил регистрацию, через почту), потому как привязать что-либо по логину бывает проблемным...

Я храню даты или в date или в datetime, зависит от потребностей. Потому что мне удобно видеть сразу где какая дата, а не timestamp, без шаманств и преобразований с консольки, сразу после запроса.

 

[dr-sm]

yok прочитай
http://ru.wikipedia.org/wiki/Суррогатный_ключ
http://ru.wikipedia.org/wiki/Внешний_ключ

тебе твоя "оптимизация" выдет боком когда появятся ссылки на пользователей в других таблицах

 

[yok]

c0dex
Сначала о
-----------------------------------------------
потому как привязать что-либо по логину бывает проблемным...
---------------------------------------------------------
вот тут и вопрос, почему проблемно, id int - 4байта, а логин хоть и уникален но может быть и 10 и более, поэтому если индексацию производить по логину то накладно., но если других таблиц не будет, то вот и вопрос.
Индекс по логину вероятно не оправдан, и именно изза веса самого поля. Да, все при условии что логин уникален.

Насчет двух таблиц в регистрации тоже думал, да подтверждающий код во второй, вобщем тут можно по разному, оптимально еще не придумал, думаю.

-~{}~ 22.03.10 16:22:

dr-sm спасибо, почитаю.

 

[c0dex]

yok
все давно уже придумали за тебя и поле id тут реально оправдано. Потому что это правильно с позиций связывания таблиц. Регистрация, то есть система с одной таблицей - регистрации не требует, хватит и капчи.

Проблемно может быть потому, что поддерживать потом систему и расширять - будет очень неудобно и все равно придешь к автоинкрементному полю. Да и чтобы сделать поле уникальным - по любому ты повесишь на него индекс. Или ты хочешь каждый раз делать проверку на существование такого логина в бд? Тогда опять же по логину придется сделать индекс.

 

[dr-sm]

yok, в таблице пользователей, если делать по нормальному, нужно как минимум два индекса:
примари кей (суррогатный внешний ключ),
юник кей по логину (и возможно статусу активности).

ПС: с чего ты взял, что в данном случае индексацию накладно делать?
у тебя к этой таблице будет доступ 99% на чтение.
часть запросов, если сделать нормально, будут читать ТОЛЬКО ИНДЕКС.
а расходы на перестройку индекса происходят только при вставке, у тебя что будет 100 человек в секунду регистрироваться ?

 

[yok]

c0dex

Регистрация, то есть система с одной таблицей - регистрации не требует, хватит и капчи.

Думаю , ты уж совсем упростил задачу. Конечно в таблице под пользователя будет одно , два поля, вероятно, но не более. Каптча это не то. А вот

Проблемно может быть потому, что поддерживать потом систему и расширять - будет очень неудобно и все равно придешь к автоинкрементному полю.

тут согласен, кто его знает, но вот и мысль, всегда можно когда возникнет необходимость ALTER, и добавить этот сурогатный ключ.

dr-sm
Опять же добавлю к вышесказанному, если потом alter то, и индекс на него потом, индекс на статус активности , ну не знаю.

И вот что я нашел, дома поднял свои скудные запасы литературы и перечитал, и проблем то нет,
уточняю:
индекс по id 4 байта, пожалуйста создается индекс по логину с префиксом 4, все, ПРОБЛЕМА РЕШЕНА!!!

Бессмысленный индекс и само поле по id, совершенно неразумные затраты при сайтах очень маленьких, такой как я делаю, это же не библиотека, ни магазин, ни еще что, форум или еще. Просто регистрация и возможно одно будет , два поля для пользователя. Ни каких внешних ключей. !!!!

И вот теперь если Вы прочтете первое мое сообщение, там четко описанны именно эти задачи :

И вот допустим , для регистрации допустим всего одна таблица. ОДНА. ИМенно.

я нашел ответ и я был прав что сомневался.
Префикс решил все.

Но все были правы, и всем спасибо за мнения.

Хотя вот задумался, индекс с префиксом 4 и просто индекс, как они по весу и ресурсозатратам отличаются, никто конкретно не разбирался или знает???

 

[Фанат]

А вот 1 почему то даже оправданный, лишнее поле int , и не необходимое, по которому формируется индекс. НЕРАЗУМНО ПОЛУЧАЕТСЯ. причем учтите из подхода одна таблица.

Согласен с автором. только я бы пошел дальше. Зачем нам регистрация, если на сайте всего одна таблица. ОДНА. ИМенно. По-моему, затраты резко сократятся, если эту бессмысленную таблицу вообще убрать

 

[craz]

+1
Зачем нам сайт, если там даже таблиц нет, мне кажется, если не делать сайт вообще, то затраты будут минимальны? не так ли?

 

[Fortop]

Бессмысленный индекс и само поле по id, совершенно неразумные затраты при сайтах очень маленьких

Что за глупость?
На маленьких сайтах эти затраты абсолютно не видны.

почему проблемно, id int - 4байта, а логин хоть и уникален но может быть и 10 и более, поэтому если индексацию производить по логину то накладно.,

Бред. "Накладность" стандартных инструментов не имеет никакого значения до тех пор пока вы не понимаете как проектировать и оптимизировать приложения.

индекс с префиксом 4 и просто индекс, как они по весу и ресурсозатратам отличаются

В гугл.

если таблица одна, и выборка идет по логину, зачем нам индекс, и само поле вообщето id INT,

Это общепринятый прием проектирования. Это не обязательно, но, до тех пор пока полностью не понимаешь сути, лучше не выделываться.
Есть еще один немаловажный момент наиболее часто применяемые приемы, впоследствии используются "на автомате", поэтому лучше развивать полезные привычки.

Вобще ресурсозатраты на запрос вероятно заточенный под INTERVAL, от timestamp , меньше чем сравнение с date.

Бред. В гугл.

Мысли есть какие??

Мысль одна - прежде чем делать какие-то выводы и суждения надо хотя бы немного знать то, о чем пишешь. В противном случае лучше не выдумывать.

Это как начинать на пк, надо научиться слепым десятипальцевым, а иначе ерунда будет

Для начала стоит научится читать и писать, иначе будет такая ерунда как у вас. Вас невозможно читать.

 

[yok]

Fortop
ну ты меня рассмешил своей болтовней.
Читай тему и конкретно помогай, а нет, не мусори.
Хотя думаю ты и не знаешь о чем речь, это как видел спецов умничали, а толком ничего не умеют, только флудить. Проверенно и доказано.
Не флудьте бессмысленными и безпочвенными замечаниями пожалуйста, хотелось бы интересные мнения знающих людей.

В большинстве случаев можно оценивать производительность путем подсчета дисковых операций. Для маленьких таблиц можно обычно принимать 1 строку за 1 операцию дискового поиска (поскольку индекс, скорее всего, в кэше). Для больших таблиц можно считать, что (при использовании индексов типа B++ деревьев) для нахождения строки потребуется

log(количество_строк) / log(длина_индексного_блока / 3 * 2 / (длина_индекса + длина_указателя_на_данные)) + 1

дисковая операция для получения строки.

Обычно в MySQL индексный блок занимает 1024 байта, а указательн - 4 байта. Для таблицы, содержащей 500000 строк и имеющей длину индекса 3 (medium integer) потребуется log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 дисковых операции поиска.

Вот тут ответ на мой вопрос думаю о префиксе, кто либо такое решал.??

от сюда
http://www.citforum.ru/database/mysql/manual/manual.ru_toc.html#Estimating_performance

 

[c0dex]

yok
тебе пытались мягко намекнуть на то, что занимаешься ты откровенной фигней. Но ты не понял.

Я не знаю на какого хрена тебе экономить байты в эпоху гигабайтных тарифов на хостинге. Придумал проблему себе и пытается ее решить. Зачем оно надо я до сих пор не могу понять.

 

[Gas]

yok
с одной стороны ты занимаешься фигнёй и c0dex,Fortop и другие правильно всё сказали. Но твоё желание копнуть глубже очень похвально, мало кто из php/mysql пользователей об этом задумывается. Сделай сначала рабочее приложение c id int и индексом на логине, а потом уже смотри в реальности как что работает, эксплейны, show status и т.д.

 

[Фанат]

yok
я думаю, ты не настолько опытен в обсуждаемом вопросе, чтобы смеяться над обсуждением? Или у тебя другое мнение на этот счет?

 

[Fortop]

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

Почему чаду (вот забавно, как можно в 40 лет быть ребенком?) еще не дали прочитать?
http://www.rsdn.ru/article/philosophy/Optimization.xml
http://www.acm.org/ubiquity/views/v7i24_fallacy.html

Вопросы топика не имеют смысла в том ключе, в каком они поставлены.
Если Вы хотите узнать механику работы индексов и вообще DB engine, то Вы явно ошиблись форумом.
Если же Вы хотите именно оптимизировать что-либо, то стоило не упрямиться и прислушаться к тому, что говорили люди выше.

Вот простая табличка (часть полей порезано)
[sql]CREATE TABLE `tours` (
`myid` char(36) DEFAULT NULL,
`P` mediumint(9) NOT NULL,
`D` int(11) NOT NULL,
`aFCK` mediumint(9) NOT NULL,
`operator` text,
`SPO` int(11) NOT NULL,
`key` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`key`),
UNIQUE KEY `myid` (`myid`),
KEY `afck` (`aFCK`),
KEY `htlcok` (`htlCoK`),
KEY `combined` (`aFCK`,`htlCoK`)
) ENGINE=InnoDB AUTO_INCREMENT=15003001 DEFAULT CHARSET=utf8 [/sql]
+-------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+------------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment |
+-------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+------------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
| tours | InnoDB | 10 | Compact | 15003102 | 147 | 2217738240 | 0 | 2054717440 | 5784993792 | 15003001 | 2010-03-18 01:18:47 | NULL | NULL | utf8_general_ci | NULL | | |
+-------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+------------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
несложно заметить, что индекс полностью помещается в памяти на сервере.

 

[yok]

c0dex
Gas
немного вернусь. Изначальный вопрос стоял так,
для маленького сайта, всего одна таблица и максимум(вероятно) с двумя полями для пользователя для хранения минимальных данных
VARCHAR(10-40). Вот задача.

Нормализацию и оптимизацию никто не отменял, ну и зачем мне поле id.
Выше все доказано.
Единственный вопрос для меня не окончательно выясненный, это
индекс с префиксом и без, различия :вес, производительность и пр.

Думаю, искать всегда надо, и пытаться думать, а не копировать чужие штамы.