Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
EuGen
Я назвал запрос со слиянием тяжелым, потому что он не будет выполняться с той же скоростью что и обыденные запросы, + при раскидывании базы по серверам эти слияния могут и в значительной степени усложнить это, также в конкретном случае, я не вижу смысла что либо выносить...
Ну вообщем буду иметь ввиду насчет оптимизации путем вынесений полей если что...
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
vanicon
Ну, я подозреваю, что если будет нужда таким образом разделить хранение БД между серверами, что части будут храниться не полностью на каждом сервере (хотя выглядит как довольно странная схема - проще создать полноценную реплику), то логично предположить, что части одной таблицы будут храниться на одном сервере. Если нет - то вините того, кто таким образом спроектировал БД. Но, думаю, самому себе никто вредить не будет.
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
armancho7777777
Отправлено: 28 Июня, 2013 - 19:58:13
Активный участник
Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011 Откуда: Москва
Помог: 221 раз(а)
vanicon пишет:
Прошу прощение если чем то задел
Проехали )
vanicon пишет:
почему вы утверждали что нужно выносить в другую таблицу какое-то поле
Из-за отсутствия полнотекстового поиска в InnoDB, который превосходит MyISAM во всём за исключением оного + инсерты. (Добавление)
EuGen пишет:
позволяет выделить удобное время для индексирования, тем самым снизив нагрузку в критичные часы
Я думал подобное реализовать без сторонних библиотек )
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
armancho7777777 пишет:
Из-за отсутствия полнотекстового поиска в InnoDB, который превосходит MyISAM во всём за исключением оного.
Для поиска я считаю что лучше такие утилиты как сфинкс и т.д, нежели таблица в MyISAM.
Ну а вообще, то мы не в ту сторону идем, спорим о процедурах о полнотекстовых поисках и п.р
А тс нужно лишь простенький блог замутить
----- Так было, так есть и так будет
armancho7777777
Отправлено: 28 Июня, 2013 - 20:11:24
Активный участник
Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011 Откуда: Москва
Помог: 221 раз(а)
vanicon пишет:
А тс нужно лишь простенький блог замутить
Так я всего лишь предположил, зачем можно вынести это поле )
Покинул форум
Сообщений всего: 356
Дата рег-ции: Июнь 2013 Откуда: Ставропольский край
Помог: 10 раз(а)
[+]
Так ничего и не понял...
Нужно так разбивать или делать большие таблицы для всего.
Статьи, категории, комменты, пользователи...
К чему тогда столько писанины о нормализации?
Да, простенький блог, но базу хочется делать как для чего-то большого, в будущем может быть расширяемого.
А можно вкратце, чем отличаются InnoDB и MyISAM?
----- ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)
vanicon
Отправлено: 28 Июня, 2013 - 20:20:28
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Hapson пишет:
А как же нормализация?
Тут главное не слишком нормализировать, потому что все зависит от конкретного приложения, и иногда приходиться денормализацию делать, для повышение производительности.
В вашем же случае, делайте так как будет удобнее работать с данными, а не например делать две таблицы для пользователей (зареганых и не зареганых)... (Добавление)
Hapson пишет:
А можно вкратце, чем отличаются InnoDB и MyISAM?
В основном блокировками, у первого блокируется только строка при параллельном доступе, а во 2 блокируется вся таблица, поэтому надо использовать InnoDB, а вообще об этом можно и в гугле почитать.
----- Так было, так есть и так будет
Hapson
Отправлено: 28 Июня, 2013 - 20:28:40
Посетитель
Покинул форум
Сообщений всего: 356
Дата рег-ции: Июнь 2013 Откуда: Ставропольский край
Помог: 10 раз(а)
[+]
vanicon пишет:
Hapson пишет:
А как же нормализация?
Тут главное не слишком нормализировать, потому что все зависит от конкретного приложения, и иногда приходиться денормализацию делать, для повышение производительности.
В вашем же случае, делайте так как будет удобнее работать с данными, а не например делать две таблицы для пользователей (зареганых и не зареганых)...
Я размышлял следующим образом:
У комментария обязательно есть:
1. его id
2. id статьиб к которой он относится
3. сам коммент
4. его статус
Далее:
1. id пользователя, если он зарегистрирован
2. дальше по id пользователя можно узнать все о нем
Или:
1. имя и email пользователя, если он незарегистрирован... и все
Ну еще есть рейтинг, который тоже может быть а может и нет.
Если все слить, то поля id пользователя, рейтинг, имя и email пользователя где-то будут, а где-то будут пустовать. Вот о чем я.
Я как бы планировал так, чтобы каждая таблица содержала минимум NULL
----- ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)
caballero
Отправлено: 28 Июня, 2013 - 20:31:15
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
В основном блокировками,
ИМХО основное - это наличие транзакций
Цитата:
К чему тогда столько писанины о нормализации?
потому что писанина - это теория БД и реляционная алгебра. А практика показывает что лишняя нормализация усложняет БД и выборки из нее. В отличие от времен когда разрабатывалась теория реляционных БД сейчас дисковое пространство стоит копейки. Поэтому проще продублировать данные чем перевязывать стопицот таблиц.
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Hapson
Я не могу вам однозначно сказать как правильно, но как бы сделал я:
1 таблица комментов, и ничего что кое-где будут пустые мейлы и т.п
А вот насчет рейтинга, это уже другое, если будет просто рейтинг типа кол-во за и против, и не надо будет смотреть кто голосовал, то тоже поместил бы в эту таблицу, а если надо знать кто голосовал, то отдельная таблица, связь один ко многим... (Добавление)
caballero пишет:
ИМХО основное - это наличие транзакций
да об этом забыл написать, тоже бывает надо....
----- Так было, так есть и так будет
caballero
Отправлено: 28 Июня, 2013 - 20:36:03
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
Я как бы планировал так, чтобы каждая таблица содержала минимум NULL
это несущественнно
Цитата:
дальше по id пользователя можно узнать все о нем
зависит от того нужно ли что то узнавать. О незареганом пользователе вы все равно узнать ничего не можете. Возможно и о зареганом ничего кроме емейла и ника ничего в данном конткесте знать не надо (или надо в очень редких случаях).
тогда просто скопировать его емейл и ник в таблицу комента и все дела
Покинул форум
Сообщений всего: 356
Дата рег-ции: Июнь 2013 Откуда: Ставропольский край
Помог: 10 раз(а)
[+]
Вообщем понятно.
Если без деления никак, то делить. А если можно без деления, то не делить. (Добавление)
caballero пишет:
зависит от того нужно ли что то узнавать. О незареганом пользователе вы все равно узнать ничего не можете. Возможно и о зареганом ничего кроме емейла и ника ничего в данном конткесте знать не надо (или надо в очень редких случаях).
тогда просто скопировать его емейл и ник в таблицу комента и все дела
это и есть пример денормализации
Ну то есть так, таблица комментов:
1. id коммента
2. id статьи
3. id пользователя
4. имя пользователя (незарегистрированного)
5. email пользователя (незарегистрированного)
6. коммент
7. статус
А рейтинг комментов уже отдельно (Добавление)
А нужно ли делать таблицу с данными незарегистрированных пользователей. Хранить там их емейлы и имена?
И еще такой момент.
Есть таблица с категориями. Есть поле для описания - char(255). Есть 10 строк, но в описаниях NULL. Вот эти NULL будут занимать место на диске?
----- ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)
vanicon
Отправлено: 28 Июня, 2013 - 20:50:00
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Hapson пишет:
Ну то есть так, таблица комментов:
Может быть полезно также сделать поле типа кол-во проголосовавших, если надо, что бы не считать по таблице рейтингов, а в таблице рейтингов хранить пользователей конкретно кто проголосовал, но тогда нужно будет при голосовании делать транзакцию, на добавление в таблицу рейтингов и обновления поля в комменте...
----- Так было, так есть и так будет
caballero
Отправлено: 28 Июня, 2013 - 20:54:32
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
А нужно ли делать таблицу с данными незарегистрированных пользователей. Хранить там их емейлы и имена?
не нужно
Цитата:
4. имя пользователя (незарегистрированного)
5. email пользователя (незарегистрированного)
Покинул форум
Сообщений всего: 356
Дата рег-ции: Июнь 2013 Откуда: Ставропольский край
Помог: 10 раз(а)
[+]
vanicon пишет:
Hapson пишет:
Ну то есть так, таблица комментов:
Может быть полезно также сделать поле типа кол-во проголосовавших, если надо, что бы не считать по таблице рейтингов, а в таблице рейтингов хранить пользователей конкретно кто проголосовал, но тогда нужно будет при голосовании делать транзакцию, на добавление в таблицу рейтингов и обновления поля в комменте...
Касательно моего случая, то нужно что...
Пользователь оставил пост. Кто-то поставил +1 этому посту - у автора поста в профиле поднялся рейтинг. А кто за что голосовал думаю совсем не нужно. (Добавление)
caballero пишет:
Цитата:
А нужно ли делать таблицу с данными незарегистрированных пользователей. Хранить там их емейлы и имена?
не нужно
Цитата:
4. имя пользователя (незарегистрированного)
5. email пользователя (незарегистрированного)
всех пользователей
Ага,теперь понял. Собственно кроме имени и email больше ничего и не нужно.
----- ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.