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

vanicon
Ну, я подозреваю, что если будет нужда таким образом разделить хранение БД между серверами, что части будут храниться не полностью на каждом сервере (хотя выглядит как довольно странная схема - проще создать полноценную реплику), то логично предположить, что части одной таблицы будут храниться на одном сервере. Если нет - то вините того, кто таким образом спроектировал БД. Но, думаю, самому себе никто вредить не будет.

Проехали )

Из-за отсутствия полнотекстового поиска в InnoDB, который превосходит MyISAM во всём за исключением оного + инсерты.
(Добавление)

Я думал подобное реализовать без сторонних библиотек )

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

Так я всего лишь предположил, зачем можно вынести это поле )

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

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

А можно вкратце, чем отличаются InnoDB и MyISAM?

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

В основном блокировками, у первого блокируется только строка при параллельном доступе, а во 2 блокируется вся таблица, поэтому надо использовать InnoDB, а вообще об этом можно и в гугле почитать.

Я размышлял следующим образом:

У комментария обязательно есть:
1. его id
2. id статьиб к которой он относится
3. сам коммент
4. его статус

Далее:
1. id пользователя, если он зарегистрирован
2. дальше по id пользователя можно узнать все о нем

Или:
1. имя и email пользователя, если он незарегистрирован... и все

Ну еще есть рейтинг, который тоже может быть а может и нет.

Если все слить, то поля id пользователя, рейтинг, имя и email пользователя где-то будут, а где-то будут пустовать. Вот о чем я.
Я как бы планировал так, чтобы каждая таблица содержала минимум NULL

ИМХО основное - это наличие транзакций


потому что писанина - это теория БД и реляционная алгебра. А практика показывает что лишняя нормализация усложняет БД и выборки из нее. В отличие от времен когда разрабатывалась теория реляционных БД сейчас дисковое пространство стоит копейки. Поэтому проще продублировать данные чем перевязывать стопицот таблиц.

Hapson
Я не могу вам однозначно сказать как правильно, но как бы сделал я:
1 таблица комментов, и ничего что кое-где будут пустые мейлы и т.п
А вот насчет рейтинга, это уже другое, если будет просто рейтинг типа кол-во за и против, и не надо будет смотреть кто голосовал, то тоже поместил бы в эту таблицу, а если надо знать кто голосовал, то отдельная таблица, связь один ко многим...
(Добавление)

да об этом забыл написать, тоже бывает надо....

это несущественнно


зависит от того нужно ли что то узнавать. О незареганом пользователе вы все равно узнать ничего не можете. Возможно и о зареганом ничего кроме емейла и ника ничего в данном конткесте знать не надо (или надо в очень редких случаях).
тогда просто скопировать его емейл и ник в таблицу комента и все дела

это и есть пример денормализации

Вообщем понятно.
Если без деления никак, то делить. А если можно без деления, то не делить.
(Добавление)

Ну то есть так, таблица комментов:
1. id коммента
2. id статьи
3. id пользователя
4. имя пользователя (незарегистрированного)
5. email пользователя (незарегистрированного)
6. коммент
7. статус

А рейтинг комментов уже отдельно
(Добавление)
А нужно ли делать таблицу с данными незарегистрированных пользователей. Хранить там их емейлы и имена?

И еще такой момент.
Есть таблица с категориями. Есть поле для описания - char(255). Есть 10 строк, но в описаниях NULL. Вот эти NULL будут занимать место на диске?

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

не нужно



всех пользователей

Касательно моего случая, то нужно что...
Пользователь оставил пост. Кто-то поставил +1 этому посту - у автора поста в профиле поднялся рейтинг. А кто за что голосовал думаю совсем не нужно.
(Добавление)

Ага,теперь понял. Собственно кроме имени и email больше ничего и не нужно.