— пока индекс в память умещается — все замечательно, как перестанет — производительность резко падает
что логично и очевидно, с диска читать медленнее, чем из памяти. Но производительность не упадет ниже чем если бы индекса вообще не было. Благо память сейчас дешевая, а раз индекс достаточно велик, чтобы не влезать в память, то имеет смысл думать о своем сервере, с хорошим объемом памяти.
— хотя об этом часто пишут, не смог добится сильного отличия в скорости между полями CHAR и VARCHAR
различие имеет место только если у вас все столбцы фикисированных типов данных, т.к. mysql гораздо легче определить смещение искомых данных. Если у вас столбец строго 15 символов, то лучше использовать CHAR, т.к. будет затрачено меньше места (на один байт для каждой строки) ла и это просто сематично, по типу данных сразу можно составить представление о самих данных. В случае CHAR, точнее фиксированных таблиц, легче восстановить таблицу в случае сбоя.
— при росте индекса скорость вставки уменьшается нелинейно и может стать критично низкой
это тоже в принципе очевидно и логично, для избежания этого есть partitions, где вставка идет только в последнюю партицию.
— индексы (особенно составные) могут занимать в несколько раз больше места чем сами данные
в данном случае производительность улучшается ценой дисковых затрат, ну ничего не поделаешь с этим. Но можно поиграть с длиной индекса, бывает это помогает уменьшить его объем без ущерба скорости
— разбиение таблиц вешь замечательная, но сильно замедляет вставку
вы про какое разбиение?
force index вообще крайне редко стоит использовать, все таки это средство обмануть оптимизатор, а поскольку он работает вполне хорошо, то сто раз стоит подумать, кто не прав, составитель запроса/индексов или оптимизатор. Но он ошибается все же иногда, так что штука полезная ;)
В любом случае, конечно, вопросы индексов напрямую зависят от данных, и делать их надо не по шаблону, а вдумчиво и вручную. Но общие правила и подходы все таки есть.
В общем мне очень понравилась наша с вами дискуссия, весьма конструктивная я считаю. Можно немного подытожить:
1. Нифига не понятно :)
2. Есть рекомендации по синтаксису доменных имен, в них "_" не рекомендован, во избежание проблем с клиентским софтом (так сказано в RFC1035)
3. Есть старые документы, прямо запрещающие использование "_" в именах хостов, доментов и т.п.
4. Есть более новые документы, разрешающие "_" в строго определенной позиции(первым символом) и в специальных DNS-записях, т.е. это алиасы на сервисы.
5. Есть чисто прикладные проблемы связанные в "_". Насколько я помню, squid, например, возможно не во всех версиях, попросту не пропускает через себя клиентов с запросами на такие домены. Админы на работе с этим сталкивались, это реальный случай.
Итого, не знаю как вы, но я сделал вывод, что все таки "_" лучше не использовать, и кстати я не вижу никаких проблем, чем дефис хуже подчерка, непонятно.
А что конкретно интересует? составьте примерный список интересующих вопросов — могу по нему написать статью, а то уж больно обширный вопрос с одной стороны, а с другой весьма неплохо расписанный в общих чертах в документациях
Описанные проблемы часто существуют по причине того, что программист может быть хорошим специалистом в php (например), но плохо разбираться в СУБД, отсюда соблазн заткнуть незнание и неумение оптимизировать запросы заглушкой кэширования. Вывод — используешь БД — надо изучить и эту область полностью, либо должен быть отдельный специалист по базам данных, что бывает редко и только в относительно крупных компаниях, насколько я знаю
Я не конца понял о чем этот стандарт, но судя по смыслу в нем предлагается использовать _ для специальных целей, что скорее даже подчеркивает тот факт, что _ нельзя использовать просто так от балды. Тут как бы сразу два нарушения — сам факт использования подчерка и расположение его на первом месте, где может быть только буква или цифра. Т.е. с таким же успехом они могли взять $, который тоже не разрешен в именах доменов или % и это бы не означало, что его теперь можно использовать где угодно.
Мутная тема ;)
К тому же есть практическая сторона. Rucenter не позволит вам зарегистриовать доменное имя с "_" и если попробуете проверить такое доменное имя на свободность, выдаст ошибку:
Название домена должно состоять более чем из одного символа, начинаться и заканчиваться буквой латинского алфавита или цифрой. Промежуточными символами могут быть буквы латинского алфавита, цифры или дефис.
Т.е. для регистратора это правило очевидно (если знаете какого нибудь регистратора, который позволяет — напишите). Понятное дело, что домен второго уровня ничем принципиально от третьего (четвертого, пятого...) не отличается и правила должны быть едиными.
В том же RFC1035 указано не 24 символа для имени а 63 для сегмента (label), т.е. этот лимит расширили. Это прям в моем предыдущем комментарии написано. Так что ICANN никого не вертит.
ASSUMPTIONS
1. A «name» (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of «domain style names». (See
RFC-921, «Domain Name System Implementation Schedule», for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
Достаточно или еще гуглом для вас поработать? ;)
Все эти стандарты в некотором смысле рекомендательные, т.е. нет службы полицаев, которые посадят или оштрафуют за то, что вы им не следуете. Так что всегда находятся люди, которые вертели на стержне все эти RFC и рекомендации как делать предпочтительно, им пофиг, у них своё видение как всё должно работать. Слава богу их меньшинство, иначе интернета могло бы и вовсе не быть в том виде, в котором мы его знаем, а были бы кучки разрозненных анклавов.
Не путайте URL и Domain Names. В URL "_" допустим, в доменном имени — нет. Конкретно стандарт RFC1035, цитирую:
2.3.1. Preferred name syntax
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
…
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
Не просто не делает, а даже не намекает для большинства специализаций пользователей. У меня в офисе ~300 машин, большинство на XP. И пока что нет ни одной причины покупать новую ОС, вместо стабильно работающей и подходящей для решения всех задач, потому что в офисе не играют в игрушки (ну не считая флэша), а IE9 там не появился бы и так, потому что у всех стоит Fx или Опера. И я думаю, что похожая ситуация у многих.
Сделала MS на свою голову хорошую ОС ;)
Получается, потому что своя переписка — это то, что написал сам. Слова оппонента — это чужая информация, разглашение которой является дурным тоном, по крайней мере на это надо спросить разрешения, что нормальные люди кстати и делают. Вопрос — можно я наш диалог выложу туда то в паблик — лично я встречал часто.
Высказывание уважительного мнения о корпорации Intel (MS/Apple/Oracle/Google) — это нормально, они действительно этого заслуживают. То, что у вас такое мнение вызывает такие специфические ассоциации — это скорее ваша проблема.
Ви всегда вопросом на вопрос отвечаете? ;)
Железо, насколько я знаю поддерживается с помощью драйверов, я еще не видел ни одной железяки, производитель которой не укомплектовал бы её драйвером для XP (если он вообще нужен).
Технологии… пожалуй повторюсь с вопросом — вы не подскажете о каких именно технологиях идет речь и неподдержка которых делает XP трупом?
Выложенная личная переписка, без предыстории, без концовки, с затертыми именами (что странно даже со стороны pravo, почему?), с сомнительным по правдивости диалогом, возможно из-за выдернутости из контекста. И даже с ощущением некоторой показушности. Непонятные цели топика, скорее похоже на пиар (а если так — то он отдает фальшью). Складывается неприятное отношение ко всем действующим лицам.
что логично и очевидно, с диска читать медленнее, чем из памяти. Но производительность не упадет ниже чем если бы индекса вообще не было. Благо память сейчас дешевая, а раз индекс достаточно велик, чтобы не влезать в память, то имеет смысл думать о своем сервере, с хорошим объемом памяти.
— хотя об этом часто пишут, не смог добится сильного отличия в скорости между полями CHAR и VARCHAR
различие имеет место только если у вас все столбцы фикисированных типов данных, т.к. mysql гораздо легче определить смещение искомых данных. Если у вас столбец строго 15 символов, то лучше использовать CHAR, т.к. будет затрачено меньше места (на один байт для каждой строки) ла и это просто сематично, по типу данных сразу можно составить представление о самих данных. В случае CHAR, точнее фиксированных таблиц, легче восстановить таблицу в случае сбоя.
— при росте индекса скорость вставки уменьшается нелинейно и может стать критично низкой
это тоже в принципе очевидно и логично, для избежания этого есть partitions, где вставка идет только в последнюю партицию.
— индексы (особенно составные) могут занимать в несколько раз больше места чем сами данные
в данном случае производительность улучшается ценой дисковых затрат, ну ничего не поделаешь с этим. Но можно поиграть с длиной индекса, бывает это помогает уменьшить его объем без ущерба скорости
— разбиение таблиц вешь замечательная, но сильно замедляет вставку
вы про какое разбиение?
force index вообще крайне редко стоит использовать, все таки это средство обмануть оптимизатор, а поскольку он работает вполне хорошо, то сто раз стоит подумать, кто не прав, составитель запроса/индексов или оптимизатор. Но он ошибается все же иногда, так что штука полезная ;)
В любом случае, конечно, вопросы индексов напрямую зависят от данных, и делать их надо не по шаблону, а вдумчиво и вручную. Но общие правила и подходы все таки есть.
1. Нифига не понятно :)
2. Есть рекомендации по синтаксису доменных имен, в них "_" не рекомендован, во избежание проблем с клиентским софтом (так сказано в RFC1035)
3. Есть старые документы, прямо запрещающие использование "_" в именах хостов, доментов и т.п.
4. Есть более новые документы, разрешающие "_" в строго определенной позиции(первым символом) и в специальных DNS-записях, т.е. это алиасы на сервисы.
5. Есть чисто прикладные проблемы связанные в "_". Насколько я помню, squid, например, возможно не во всех версиях, попросту не пропускает через себя клиентов с запросами на такие домены. Админы на работе с этим сталкивались, это реальный случай.
Итого, не знаю как вы, но я сделал вывод, что все таки "_" лучше не использовать, и кстати я не вижу никаких проблем, чем дефис хуже подчерка, непонятно.
Спасибо вам за интересную беседу ;)
минералыкэши? ;)Описанные проблемы часто существуют по причине того, что программист может быть хорошим специалистом в php (например), но плохо разбираться в СУБД, отсюда соблазн заткнуть незнание и неумение оптимизировать запросы заглушкой кэширования. Вывод — используешь БД — надо изучить и эту область полностью, либо должен быть отдельный специалист по базам данных, что бывает редко и только в относительно крупных компаниях, насколько я знаю
Мутная тема ;)
Достаточно или еще гуглом для вас поработать? ;)
Все эти стандарты в некотором смысле рекомендательные, т.е. нет службы полицаев, которые посадят или оштрафуют за то, что вы им не следуете. Так что всегда находятся люди, которые вертели на стержне все эти RFC и рекомендации как делать предпочтительно, им пофиг, у них своё видение как всё должно работать. Слава богу их меньшинство, иначе интернета могло бы и вовсе не быть в том виде, в котором мы его знаем, а были бы кучки разрозненных анклавов.
Сделала MS на свою голову хорошую ОС ;)
Железо, насколько я знаю поддерживается с помощью драйверов, я еще не видел ни одной железяки, производитель которой не укомплектовал бы её драйвером для XP (если он вообще нужен).
Технологии… пожалуй повторюсь с вопросом — вы не подскажете о каких именно технологиях идет речь и неподдержка которых делает XP трупом?
if ($host ~* "([a-z0-9\-]+)(?<!^www)\.example\.com$") { rewrite }