С точки зрения простоты реализации желательно ЛЮБЫЕ модели представлять в виде взаимосвязанных таблиц (реляционной модели), так как рынок реляционных СУБД давно освоен и имеется множество методик, рекомендаций, литературы — как это делать правильно и чтобы все быстро работало. Наиболее популярен для обработки информации в таком виде язык стрктурированных запросов SQL, программных продуктов, использующих различные его диалекты — тысячи. Известно что существуют задачи, плохо проектируемые в реляционных моделях, в основном связанные с тем что объекты очень сильно отличаются друг от друга по набору свойств. В реляционной модели в этом случае приходится делать «широкие» таблицы, содержащие исчерпывающий перечень колонок, 90% значений в которых будут пусты, либо для каждого вида объекта вводить свою таблицу, что резко снижает скорость работы с такой БД. В этом случае лучше переходить на объектно-ориентированную СУБД (например, Cache) либо хранить данные в формате, допускающем вариации в узлах (например, в XML). Скорость обработки больших массивов в этом случае ниже, но за счет того, что база становится компактной, скорость работы в целом возрастает. А в случае XML даже отпадает возможность создавать отдельное описание для структуры таблиц — формат XML несколько избыточен, зато сам себя документирует, за это его и любят. К таким неструктурированным базам тяготеют также вычислительноемкие расчеты — распознавание образов, речи, расчеты протекания физических процессов и химических реакций и пр. Иногда даже такие задачи необходимо делать в реляционной модели, чтобы ускорить расчеты определенных этапов, на которые уходит львиная доля процессорного времени. Вообще это отдельная область науки, можете ознакомиться с трудами классиков, например с «Библией» реляционной модели, автор Д. Кнут. Исходя из сказанного ответ на вопрос — в табличном виде оптимально представлять наборы объектов, обладающих одинаковыми свойствами, для которых почти все свойства используются и имеют различные значения (нет «пустот"). Количество таких объектов для современных баз данных может быть достаточно велико — лично я работаю с базами, содержащими миллионы записей, но при этом число различных таблиц (видов объектов с разными наборами полей) невелико и составлет от нескольких десятков до нескольких сотен.
