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