Чему будет равен результат выполнения программы, если ввести значения для a=16 program c22; var a: integer; begin readln(a); if (a mod 2=0) then a: =a div 2; write(a); end

Вводим значение а=16.
Далее: "если а- четное, то делим его пополам". У нас 16 - четное, поэтому делим пополам и получаем 8. Это и есть ответ.
ответ: 8

using System.Threading.Tasks;

namespace trapec

{

   class Program

   {

       static void Main(string[] args)

       {

           Console.WriteLine("[Введите символ, из которого будете рисовать трапецию]");

           string c = Console.ReadLine();

           Console.WriteLine(" " + c + " " + c + " " + c + " " + c + "");

           Console.WriteLine(" " + c + " " + c + " " + c + " " + c + " " + c + " " + c + " ");

           Console.WriteLine(" " + c + " " + c + " " + c + " " + c + " " + c + " " + c + " " + c + " " + c + " ");

           Console.WriteLine("[Поздравляем, вы нарисовали самую идеальную трапецию во вселенной]");

       }

   }

}  

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