Языки программирования – 10

База данных это набор таблиц, в которых хранятся однотипные данные. Для примера на всё той же древней пивной базе.
Вот куча её таблиц:

Содержимое таблицы tblTov (от «товар»):

В этой таблице содержится всё, что может быть отгружено покупателям. В этом смысле данные в таблице однотипны. Но тут и пиво и рекламная продукция, т.е строки таблицы тоже могут отличаться. Чтобы быстро выбирать строки одного типа заводятся отдельные поля. В данном случае только одно поле – TovGr (товарная группа).
А это список отгрузочных накладных:

В нем есть дата накладной, покупатель и прочая информация. По накладным может отгружаться что угодно, но у этих документов одинаковая функция – они взводят долг (что бы по ним не отгружалось). Информация однотипна по свой функции в базе. Оплата же гасит долг.
А это содержимое накладных, где по каждой накладной может быть сколько угодно строк:

Информацию можно смотреть в виде таблиц. Но неплохо бы ещё иметь инструмент, который позволил бы по ней быстро считать.
Типовой инструмент – SQL строка. Она позволяет выбрать из базы данных любую информацию, написав некое выражение на языке SQL запросов.
Причём все системы позволяют даже не писать ничего на этом языке. Этим занимается конструктор запросов. Пусть я хочу узнать сколько «штук» (обычно литров)  продукции было отгружено по типам тары.
Я выбираю все таблицы, из которых мне потребуется информация и конкретную информацию из них:

В данном случае у меня выбраны список накладных, состав накладных и справочник единиц измерения. Список и состав накладных связаны по идентификатору накладной NaklID, а единица измерения содержится в поле UniID (по которому состав накладных связан с справочником единиц измерения (tblUni). «Штуки» записываются в поле DocKol таблицы tblNaklSost.
Результат выборки информации:

В боках по 30 литров покупали больше всего и почти две тонны забрали в пятилитровые банки из-под питьевой воды.
На самом деле перетаскивание таблиц и полей мышью привело к тому, что в программе появился такой SQL текст:

Тут написано:
1] какую информацию надо выбрать (после SELECT).
2] из каких таблиц надо выбрать информацию (после FROM)
3] по каким полям связаны таблицах (JOIN, ON)
4] как сгруппировать информацию если это надо (GROUP). В данном случае группировать надо только по единице измерения (UniID), а количество надо суммировать.
Язык запросов SQL появился давно. Ещё на втором курсе я болталась по программистским спецкурсам, и на одном из них рассказывали про Oracle и язык SQL, который там можно использовать. Но рассказывали это всё теоретически. Показывать было не на чем потому что технология времён больших машин уже была а инструментов для персональных компьютеров ещё не было.
Но как-то странно когда с помощью компьютера нельзя делать то, для чего он лучше всего подходит, т.е искать и суммировать.
Нет нормального инструмента? Тогда нужен хотя бы какой-то чтобы хоть как-то но можно было работать. Так придумали файл типа DBF.
DBF позволяет хранить в себе одну таблицу, которая (если открывать её специальными средствами) выгладит как таблица:

Но если открыть этот файл текстовым редактором:

… то видно, что вначале там какая-то служебная информация (включая названия полей) а потом лежат строки, точнее последовательности байт одинаковой длины, в которых записаны строки.
Те, кому надо было работать работали с DBF-ами. Интересно, что на факультете считали, что работать с DBF-ами вообще нельзя. Есть в этом конечно некий снобизм. Но и причины есть. Считалось, что работа с данными это не баловство в серьёзное дело, требующее работы квалифицированного специалиста. Такой специалист и должен написать инструмент, дающий программисту возможность пользоваться SQL строками.
Есть шуточные критерии готовности программы: 1) работает в своих руках 2) работает в чужих руках 3) работает при объемах справочников от 10 тысяч строк. Казалось бы 10 тысяч строк это много, но фирма купи-продай, торгующая всем, что может поместиться в большую сумку за год легко выйдет на справочник товаров сопоставимых размеров. Пусть этой фирме надо посчитать суммы по месяцам продаж и пусть информация храниться на одном компьютере, а директор, которому нужна эта информация работает на другом компьютере. Можно передать по тем самым тонким сетевым каналам всю информацию и заставить машину директора это всё считать. Просто для ориентировки справочник товара в 10 000 строк это код (байт 6) + наименование (байт 30) + ещё что-нибудь (байт 20) = 56 байт на строку. 56 байт * 10 000 строк = 560 000 байт. И это всё надо перекинуть в виде сетевых пакетов. Это всё будет работать быстро пока базы почти пустые. Но по мере наполнения баз информацией это будет работать всё медленнее. Безграмотно написанная база это брак, но выясниться это не сразу. Есть масса вещей которые можно написать плохо. Предполагается, что SQL строка с возможностью запросить информацию должна снять хотя бы часть плохих вариантов написания (т.к выбирать данные из базы будет программа специалиста, а не неизвестного криворукого программиста). Даже сейчас проблемы возникают сплошь и рядом. Понятно, что 25 лет назад с криворукостью было так же а техника была слабее, т.е тяжёлые продукты с переброской больших данных могли положить и машину и локальную сеть (перегрузив её работой).
Средства для работы с SQL на персональных компьютерах появились в конце 90-х. Стали нормой в нулевых.
Всё вместе всегда состоит из сервера базы данных (т.е программы, получающей SQL строки и возвращающей наборы данных) и программы – клиента, которая запрашивает у сервера информацию и отображает ей на экране. Сервер в данном случае не компьютер а установленная на компьютере программа. И сервер и клиент могут быть установлены на одном компьютере, но чаще всего сервер находится на самой мощной машине, которая должна быстро обрабатывать информацию и пересылать клиентам желательно небольшой по объему данных результат (чтобы не загружать сеть). Сервер и нужен для того, чтобы на нём считать и не отправлять никуда большие объемы информации для обсчёта.
Основное и единственное тут правило – передача данных должна быть минимальна. При реальной работе следование всем этим правилам приводит к тому, что программный продукт становится очень неудобным, т.к слишком мало информации. Работа с DBF-ами не создавала таких проблем. Видимо, инструмент был сделан достаточно аккуратно чтобы при открытии файла больших размеров не читать сразу всё, а читать и передавать «окнами» по несколько строк. Результат же выполнения SQL стоки это всегда считывание всех запрошенных строк. Вначале при всей аккуратности это работало даже медленнее чем DBF. Быстродействие начало сказываться толкло при массовом и принципиальном увеличении мощности машин и объемов доступной оперативной памяти. Но чувствительность к объему передаваемой информации никуда не делась. Реагировать на это уже тогда приходилось выводом на экран только накладных на один день, например, чтобы объем передаваемой информации не был слишком большим. Эти ограничения стараются делать «невидимыми»  но они есть. Интернет же обычно медленнее локальной сети потому работа в нем чем-то напоминает работу с SQL-ем году в 2000-м, т. е возможность есть но требуется максимальная экономия передачи информации.
Человеку, который вводит накладные неудобно видеть только ту накладную которую он сейчас вводит. Потому, что это пачка бумаги. Лучше сверять галки на бумажках со строками на экране. Но с другой стороны использовать информацию как обои тоже нерационально, а при показе списка накладных происходит именно так (обычно не нужен весь этот список). Компромиссным решением может быть например показ не только вводимой накладной но и пяти строк введённых перед этим, т.е и информации немного и видно, что уже засунуто в базу.
Стандарт Интернета – вывод найденной информации по 20-50 строк. Это то, чего так и не появилось в базах данных в локальных сетях. В Интернете же в его малой скоростью это используется постоянно, т.к это очень чувствительная к передаваемым объемам среда.