Linux a. run command cd; mkdir -p test/{test1, test2, test3}/{abc, def, ghi}; touch test/test{1, 2, 3}/abc{1, 3, 5, 7}{a, b, c, d, e, f}.txt; touch test/test{1, 2, 3}/{abc, def}/testfile; cd - b. output (using echo and wildcards) names of files in all 3 dirs (test1, test2 & test3) with any digit in their names with the final letter before extension (.txt) being "f". c. output all files with .txt extension in directory test1. d. output everything in test1 directory. note: in all output commands use single symbol substitution for representing single symbol and multi-substitute symbol in opposite case. make sure commands will work no matter in which place in filesystem they are run

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

program z1; (Начало программы)

var n, s, i, c:integer; (Раздел описания переменных, n(кол-во чисел), s(сумма чисел), i(счетчик), с(число, введенное с клавиатуры))

begin (тело программы)

writeln ('Кол-во чисел?'); (подсказка для пользавателя)

readln (n); (считывание переменной)

s:=0; (обнуляем переменную)

For i:= 1 to n do begin (цикл будет повторяться от 1 до N; т.к в цикле будет несколько действий открываем операторные скобки (begin\end), начало цикла)

writeln ('Введите число'); (подсказка для пользавателя)

readln(c); (считывание переменной)

If c>0 then s:=s+c; (если с>0 тогда к сумме мы прибавляем число) 

end; (конец цикла)

writeln ('Сумма=',s); (подсказка для пользавателя и ответ)

readln(s); (считывание переменной)

readln; (считывание)

end.(конец программы)