например, имеются данные , которые хорошо ложатся в иерахическую модель :
система "органайзер" , которой есть абстрактная задача, и ее наследники — конкретные типы задач (со своими полями)

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

или лучше хранить все задачи в одной таблице (создав поле "тип задачи")

Здравствуйте, Sergey__, Вы писали:


S__>например, имеются данные , которые хорошо ложатся в иерахическую модель :
S__>система "органайзер" , которой есть абстрактная задача, и ее наследники — конкретные типы задач (со своими полями)

Однозначно "хранить все задачи в одной таблице (создав поле "тип задачи")". Данные должны быть нормализованы.

Здравствуйте, Sergey__, Вы писали:


S__>например, имеются данные , которые хорошо ложатся в иерахическую модель :
S__>система "органайзер" , которой есть абстрактная задача, и ее наследники — конкретные типы задач (со своими полями)

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

S__>или лучше хранить все задачи в одной таблице (создав поле "тип задачи")

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

Здравствуйте, Sergey__, Вы писали:

S__>имеет ли смысл создавать под каждый тип задачи свою таблицу ?

Как правило, отдельные сущности хранятся в отдельных таблицах.

S__>не очень хочется плодить излишние таблицы и усложнять процедуру обхода всех задач во всех таблицах....

А такая процедура будет нужна? Зачем?

Здравствуйте, Sergey__, Вы писали:


S__>например, имеются данные , которые хорошо ложатся в иерахическую модель :
S__>система "органайзер" , которой есть абстрактная задача, и ее наследники — конкретные типы задач (со своими полями)

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

S__>или лучше хранить все задачи в одной таблице (создав поле "тип задачи")

1. Решить по каким критериям отбираются задачи (для обхода задач), т.е. по каким полям чаще всего осуществляется поиск. Таких полей обычно не много.
2. Хранить все задачи в одной таблице.
3. В одном поле этой таблицы хранить все характеристики задачи, в виде JSON
4. Остальные поля таблицы — "поисковые поля", из п.1

Здравствуйте, Буравчик, Вы писали:

Б> 3. В одном поле этой таблицы хранить все характеристики задачи, в виде JSON

Это чтобы база не казалась примитивной в стиле "а чо у тебя так быстро всё работает? Может, оно и не работает вообще?"

Здравствуйте, DenisCh, Вы писали:

DC>Это чтобы база не казалась примитивной в стиле "а чо у тебя так быстро всё работает? Может, оно и не работает вообще?"

Нет, это один из вариантов реализации

Здравствуйте, Буравчик, Вы писали:

Б> DC>Это чтобы база не казалась примитивной в стиле "а чо у тебя так быстро всё работает? Может, оно и не работает вообще?"
Б> Нет, это один из вариантов реализации

Ну тогда сразу всю базу в json одним куском. А что, тоже вариант...

04.10.2017 6:20, DenisCh пишет:
> Ну тогда сразу всю базу в json одним куском. А что, тоже вариант...
> <https://github.com/abbat/avalon&gt;

не, сразу не надо.
надо в XML.
и парсить, парсить, парсить...

Здравствуйте, Sergey__, Вы писали:
S__>например, имеются данные , которые хорошо ложатся в иерахическую модель :
S__>система "органайзер" , которой есть абстрактная задача, и ее наследники — конкретные типы задач (со своими полями)

S__>имеет ли смысл создавать под каждый тип задачи свою таблицу ?
S__>не очень хочется плодить излишние таблицы и усложнять процедуру обхода всех задач во всех таблицах....
S__>или лучше хранить все задачи в одной таблице (создав поле "тип задачи")
Куда и насколько хорошо "ложатся" данные видно не из схемы данных, а только и исключительно из _запросов_.
Вам надо начать именно с этого: какие запросы должна выполнять ваша база.
Не заглядывая в ТЗ, кажется, что вводить дополнительные таблицы здесь не нужно — очень трудно придумать запросы, которые бы оправдали такой дизайн.