Правильно ли разбивать на две таблицы?

Question

[Дмитрий Б]

Здравствуйте. У меня есть таблица `tasks` (база MySQL). В ней поля id, name, type... И штук 15 параметров типа performer, performer_method, performing_interval... И параметры будут дополняться.

Скажите пожалуйста, как лучше: разбить на две основные данные о задаче и её параметры на две таблицы или всё в одной оставить?

Использую Yii, в данной таблице будет хранится больше 100 000 записей и часто обновляться

Answer 1

[Sergey Romanov]

Если отношение 1-1 то я бы не стал разбивать на таблици. При разбитии может роаботать даже медленнее если нужно делать объединения.

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

Но это мой личный опыт. Возможно я не прав.

Comments

[Дмитрий Б]

Слава богу я сам себе заказчик :D Решил сделать 1-1, так выходит на порядок меньше кода и проблем, да и приятней работать. Если уж перевалит за 50 полей, то придётся переписать

[Sergey Romanov]

Я использую такую технику. Я в поля ложу только то что использую в запросах. А все остальное сохраняю как текст в JSON. Тогда таблица всегда небольшая в плане количества полей но всегда можно что то добавть так как механизм уже на месте.

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

Потом я гружу джейсов в специальный класс, где достаю значения чере ->get('field_name', $default) и там уже можно и по умолчанию опустить, и если нету то нет и ошибки. Очень удобно.

[Дмитрий Б]

Изначально так было, параметры хранились в JSON. Но это не очень удобно в использовании. Тем более, что Yii не поощеряет работу с массивами в моделе в качестве аргументов

Answer 2

[1Michael1]

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

Comments

[Дмитрий Б]

"...в данной таблице будет хранится больше 100 000 записей и часто обновляться..."
Я делаю задачи не для людей. Задачи используются для запуска нужных классов по определённым параметрам.

[Дмитрий Б]

В БД обязательно

[1Michael1]

@xoma
лично у меня мнение двоякое... да, вроде как такое работать будет везде, но:
- очень много зависит от количества задач, которые нужно обработать в единицу времени + постоянное их дополнение. из моего опыта могу сказать, что когда приходит в секунду даже по 10 задач на выполнение - база начинает тормозить (а если учесть, что есть разграничения на приоритеты + индексация...)
- проблема при работе с БД в том, что можно нормально организовать только 1 процесс/поток для получения тасков. в противном случае могут быть проблемы с синхронизацией доступа к одной и той же задаче

@PiloTeZ
если делать не для людей, тогда зачем вообще делать?
если хоть как-то косвенно это касается людей - уже делается "для людей"
очереди всегда используются для внутренней логики. вопрос в скорости их обработки и синхронизации.
мое мнение: я бы не реализовывал очередь в БД, если бы играла роль скорость ее обработки. если не важно когда это выполниться, главное, чтоб выполнилось и это будет обрабатываться только 1 точкой входа - тогда можно и в БД
если выбор останется за БД, тогда я посоветовал бы не плодить (добавлять) колонки, а ввести колонку с конфигурацией, где будут совмещены те параметры, которые нужны для инициализации/запуска (к примеру: класс, метод, входящие параметры и т.п.)

Answer 3

[Владимир]

В одном проекте аодобная табличка разрослась до 320 полей. Это реально не удобно. Имхо, когда возможен такой рост, лучше разбить на 2 таблицы, в одной хранить то, что всегда не будет изменяться и табличка типа ключ-значение для изменяемых параметров. Выборку получаем интересную, похожую на пример
stackoverflow.com/questions/7674786/mysql-pivot-table

Comments

[Дмитрий Б]

Ничего себе табличка разрослась :D Надеюсь у меня такого не будет )) Спасибо!