| 1.1, User294 (ok), 03:08, 13/05/2008 [ответить]
| +/– | |
Там же и об отказоустойчивости написано неплохо...
...вот только как водится, сапожник по традиции без сапог - отказоустойчивости данного блога незачот - в процессе чтения оного получилось вот так ;)
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, support@hc.ru and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.34 Server at www.insight-it.ru Port 80
| | |
| 1.2, dopperst (?), 06:40, 13/05/2008 [ответить]
| +/– |
Вот особенно удивил пункт Денормализация.
Мне очень странно, почему не предложено вместо этого использовать срезы. Если их нет в СУБД, можно (даже в мускуле, даже древнем) сделать select into - и сохранить данные во временную табличку.
Так что незачот. Информации уйма, а сомых простых и, как обычно, эффективных вещей не описано.
| | |
| |
| 2.3, PavelR (??), 07:12, 13/05/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Это Вам "незачот". Даже объяснять не хочется, почему.
Но тем не менее, чтобы не быть голословным:
Временные таблицы, сортировки на дисках:
1. убивают производительность в ноль.
2. содержат неактуальные данные, не всегда применимо
3. не всегда целесообразно.
4. AFAIK временные таблицы будут разными для разных сессий/транзакций
В качестве дополнительного средства в специфических случаях оно конечно может быть применимо. Но мне кажется что уже тут написано больше буков "по теме", чем в исходном абзаце "Денормализация"
| | |
| |
| 3.6, dopperst (?), 09:29, 14/05/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Вот тоже не хочется в дискуссию пускаться, но :
1) производительность в ноль не убивается, так как как делался запрос на выборку один, так он один и делаться будет. А вот данные будут в нормальной форме храниться. Это огромный плюс. Кроме того, только процесс создания среза способен замедлить решение. Но если хорошо подумать, нужно рассматривать либо эту проблему, либо проблему неактуальности данных, о которой вы отдельно говорите. Одновременно они не встретятся.
2,4) Неактуальные данные будут только тогда, когда именно временные таблички создаваться будут. В "вашем" случае, кстати, после "денормализации" в том понимании в котором она предполагается в этой статье, будет неизбежно возникать дублирование информации. Т.е. без дополнительных (и очень больших) усилий актуальной информация не будет даже в режиме одной сессии для одного пользователя.
3) Целесообразно действительно не всегда. Но это не аргумент против. Масштабирование тоже не всегда целесообразно.
Так что ваше расстройство моим отзывом недостаточно, всё-таки, аргументировано.
| | |
|
|
| 1.4, Все тот же аноним (?), 09:50, 13/05/2008 [ответить]
| +/– |
Опоздала статья года на три. Кластеры серверов приложений, асинхронные фреймворки, линейное масштабирование и даже Hadoop + Hbase - уже давно не экзотика.
| | |
| 1.5, ZANSWER (??), 12:01, 13/05/2008 [ответить]
| +/– |
 Хорошая статья, автор молодец, всем кому не нравится, кидайте ссылки на свои труды, оценим, а то только и можно прочеcть в блогах большинства, сопли о их не кому не нужной жизни...:)
| | |
|
