Таблица users(
id
name
email
registered
max_score
);
Как лучше организовать хранение данных в таблицах?
Здравствуйте.
MySQL:
полагается, что данные, хранимые здесь, будут обновлятся раз в месяц, не чаще.
а теперь есть ещё таблица
данные в этой таблице будут менятся где-то раз в 3 дня.
Так вот, я не знаю. Кто-то гворит что лучше держать 2 таблицы (как здесь), а кто-то говорит, что можно их объединить (т.е. доавить поле scores.score в users как users.score).
Можете ли вы сказать как оптимальней, и почему, если не трудно??
MySQL:
Код:
полагается, что данные, хранимые здесь, будут обновлятся раз в месяц, не чаще.
а теперь есть ещё таблица
Код:
Таблица scores(
id //id из users.id
score
);
id //id из users.id
score
);
данные в этой таблице будут менятся где-то раз в 3 дня.
Так вот, я не знаю. Кто-то гворит что лучше держать 2 таблицы (как здесь), а кто-то говорит, что можно их объединить (т.е. доавить поле scores.score в users как users.score).
Можете ли вы сказать как оптимальней, и почему, если не трудно??
Раз в 3 дня ИМХО не так часто, чтобы отделять эту единственную колонку.
Вот если бы это был счетчик "сколько людей прочли" для информационной единицы (напр. новости), на мега-посещаемом (пусть и в перспективе) сайте, то да, несомненно отделение необходимо, а так, делай по своему усмотрению, если тебелишняя таблица не мешает в БД, создавай :)
Вот если бы это был счетчик "сколько людей прочли" для информационной единицы (напр. новости), на мега-посещаемом (пусть и в перспективе) сайте, то да, несомненно отделение необходимо, а так, делай по своему усмотрению, если тебелишняя таблица не мешает в БД, создавай :)
UAS, по большому счету при такой нагрузке на таблицы, как ты описал не имеет значения каким из этих способов ты их организуешь. Оба варианта которые ты описал вполне нормальные и могут хорошо работать.
просто в проекте задумывается так, что единоразово раз в 3 дня будет обновляться таблица scores. в перспективе записей в таблице может перевалить за 3000-4000 человек(записей). вот я и думаю, может вынести в отдельную таблицу, или никакой разницы какую таблицу обрабатывать...
Цитата:
Вот если бы это был счетчик "сколько людей прочли" для информационной единицы (напр. новости), на мега-посещаемом (пусть и в перспективе) сайте, то да, несомненно отделение необходимо
Гы!)) А можно объяснить почему, если не трудно
ЗЫ: просто впервые делаю какой-то загружаемый скрипт, опыта в разработке сильно посещаемых систем почти ноль
Цитата: UAS
просто в проекте задумывается так, что единоразово раз в 3 дня будет обновляться таблица scores. в перспективе записей в таблице может перевалить за 3000-4000 человек(записей). вот я и думаю, может вынести в отдельную таблицу, или никакой разницы какую таблицу обрабатывать...
Гы!)) А можно объяснить почему, если не трудно
ЗЫ: просто впервые делаю какой-то загружаемый скрипт, опыта в разработке сильно посещаемых систем почти ноль
Гы!)) А можно объяснить почему, если не трудно
ЗЫ: просто впервые делаю какой-то загружаемый скрипт, опыта в разработке сильно посещаемых систем почти ноль
Да разве ж 3000-4000 это много? ИМХО "много" (даже скорее ОБЬЕМНО) - таблицы с 3 дюжинами колонок (40% из которых - текстовые поля) и более чем на 100 000 записей.
Обьяснить? Поскольку никогда не обладал даром переносить технические статьи в разряд устного народного творчества, пересказывать не стану, даю источник :) - http://lib.protoplex.ru/lib_show/120.html
Я не имею ввиду, что это святая истина и её стоит беспрекословно соблюдать, нет, скорее просто пища к размышлениям.
Я в данном случае посоветую UAS'у выбрать вариант с одной таблицей. Записей не очень много, обновляются достаточно редко. Думаю, в базе есть и другие таблицы. Мускул при сложных запросах часто не очень удобен - приходится использовать всякие join'ы или вообще временные таблицы. Поэтому моё решение таково - если нет нужны выделять что-то в отдельную таблицу, то и не надо этого делать.
Спасибо всем. Буду разбираться...
Чё-то я намудрил... По расчетам получается 6000 запросов к БД!)))))) Буду переделывать, а то хостер на кол посадит))
Чё-то я намудрил... По расчетам получается 6000 запросов к БД!)))))) Буду переделывать, а то хостер на кол посадит))
Организовывать структуру БД нужно сразу правильно, чтобы в будущем не было головных болей с переделкой структуры.
Автор, оставь вариант с 2 таблицами, так как он исключит хранение избыточных данных.
ИМХО. Кроме того, поле users.max_score можно убрать, так как его всегда можно посчитать по таблице scrores.
Автор, оставь вариант с 2 таблицами, так как он исключит хранение избыточных данных.
ИМХО. Кроме того, поле users.max_score можно убрать, так как его всегда можно посчитать по таблице scrores.
Цитата: InterWen
Да разве ж 3000-4000 это много? ИМХО "много" (даже скорее ОБЬЕМНО) - таблицы с 3 дюжинами колонок (40% из которых - текстовые поля) и более чем на 100 000 записей.
Хм... странные понятия у вас про "объемные таблицы"... 100 тыс записей - это маленькая таблица. Это очень немного потому как на таких объемах практически не видны плюсы и минусы разных БД (с определенными поправками конечно). Они становятся видны на таблицах от 1-2 миллионов записей.
А вообще объемная таблица - это например 15 полей (1 счетчик, 4 текста, остальное инты) на 68 миллионов записей. Просто почти полгода с подобными зверьми работал - удовольствие то еще надо сказать. Самые простые действия могут занимать достаточно много времени.
Ну а для MySQL даже 1 миллион уже большая таблица. Потому ее и не используют в серьезных проектах.
Вообще-то связи "один к одному" являются нежелательными. Потому что приходится сначала искать данные в одной таблице, потом в другой.
Имеет смысл разве что при разделении по правам доступа: юзеры на одну таблицу имеют право записи, а на другую - только чтение.
Имеет смысл разве что при разделении по правам доступа: юзеры на одну таблицу имеют право записи, а на другую - только чтение.
Цитата: RussianSpy
Ну а для MySQL даже 1 миллион уже большая таблица. Потому ее и не используют в серьезных проектах.
а какие субды используют тогда?
Которые неMySQL...