Субд в линукс что это

Обновлено: 04.07.2024

Заметил, что когда спрашиваешь кого-нибудь, особенно на собеседовании, какие типы СУБД существуют, то первое что вспоминают многие – это реляционные базы данных, и NoSQL, а вот про разновидности часто забывают или не могут сформулировать их отличие. Поэтому начнем с простого перечисления наиболее используемых.

Тем, кому не хочется долго читать, может сразу перейти на итоговую таблицу .

Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.

Реляционные СУБД

Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.

Наиболее известные СУБД такого типа - Oracle, Microsoft SQL, PostgreSQL, MySQL.

Когда выбирать реляционную СУБД

Один из основных признаков, который говорит о том что нужно выбирать реляционную СУБД – это высокая нормализация данных. Дополнительными признаками будет необходимость обработки большого кол-ва коротких транзакций, с большей долей операций на вставку

Когда не выбирать реляционную СУБД

Если предполагается хранить не структурируемые данные, или наоборот очень простые структуры типа ключ-значение, то лучше посмотреть в сторону документных СУБД и специализированных СУБД типа ключ-значение соответственно.

Так же один из признаков, что имеет смысл подумать не о реляционных СУБД, это такой факт как необходимость часто обновлять значения в одних и тех же строках. Обычно это обходится "дорого" в реляционных СУБД, и нужно применять "продвинутую магию" что бы делать это корректно.

Конечно, тут есть много «но», или «а если очень хочется», и других ситуаций, когда данные рекомендации можно игнорировать. Это нормально, особенно когда за дело берется эксперт, который знает как это сделать.

СУБД типа ключ-значение

Наверное один из самых простых типов СУБД. В упрощенном виде, это некая таблица с уникальным ключом и собственно связанным с ним значением, в котором может быть что угодно. Чаще всего такие СУБД используют для кэширования, т.к. они очень быстро работают, а это и не сложно, когда есть уникальный ключ, и запрос возвращает только одно значение. У некоторых представителей данных СУБД есть возможность работать полностью в памяти, а так же есть возможность задавать срок жизни записи, после истечения которого, записи будут автоматически удаляться.

Наиболее известные СУБД такого типа - Redis и Memcached.

Когда выбирать СУБД ключ-значение

Когда не выбирать СУБД ключ-значение

Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.

Документные СУБД

Документные или документно-ориентированные СУБД - это одна из наиболее популярных разновидностей NoSQL СУБД, где основной единицей логической модели данных является документ - структурированный текст, с определенным синтаксисом.

Иногда встречаются мнения что модель данных в документных БД похожа на модель данных в объектно-ориентированных базах данных. В этом есть доля правды, единственная реальная разница между ними заключается в том, что базы данных документов только сохраняют состояние, но не поведение.

Так же, само название "документо-ориентированная" подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.

Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.

Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.

Когда выбирать документную СУБД

Если нужно хранить объекты в одной сущности, но с разной структурой. Если нужно хранит структуры, включая объекты, списки и словари, особенно в формате близкому к JSON.

На самом деле область применения документных СУБД очень широкая. Их можно использовать как компактную базу данных для отдельно взятого микро-сервиса, так и для вполне масштабных решений, в качестве хранилища состояний чего-либо.

Когда не выбирать документную СУБД

Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.

Графовые СУБД

Графовые СУБД - специфичный тип, предназначены для работы с графами, с их узлами, свойствами, и произвольными отношениями между узлами.

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

Известные представители этого типа субд - Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.

Когда выбирать графовые СУБД

Точно стоит обратить внимание на графовые СУБД, если строите какое-то подобие социальной сети, или реализуете систему оценок и рекомендаций. Ну и во всех случаях когда вы хорошо понимаете что такое графы, и для чего это нужно.

Когда не выбирать графовые СУБД

Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.

Колоночные СУБД

Колоночные СУБД очень похожи на реляционные. Они так же состоят из строк, которые имеют атрибуты, а строки группируются в таблицах. Различия в логических моделях несущественные, а вот на уровне физического хранения данных различия значительные.

В реляционных СУБД данные хранятся "построчно", это означает что для считывания значения определенной колонки, придется прочитать практически всю строку, как минимум от первой до нужной колонки. В колоночной СУБД данные хранятся "поколоночно", т.е. колонка - это как отдельная таблица. Соответственно чтение будет происходить из конкретного столбца сразу. На практике это реально работает очень быстро (проверено мной на нескольких реализованных хранилищах данных).

Основные преимущества колоночных СУБД – эффективное выполнения сложных аналитических запросов на больших объемах, и легкое, практически мгновенное, изменение структуры таблиц с данными, плюс существенная компрессия и сжатие, которое позволяет значительно экономить место.

Яркие представители колоночных СУБД - Sybase IQ (ныне SAP IQ), Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra.

Когда выбирать колоночные СУБД

Один из весомых аргументов за использование именно колоночной СУБД - это если вы хотите построить хранилище данных, и планируете делать выборки со сложными аналитическими вычислениями. Косвенный признак, который так же может сигнализировать о том, что имеет смысл, хотя бы посмотреть в сторону колоночных СУБД - это если количество строк, из которых делаются выборки, превышает сотни миллионов.

Когда не выбирать колоночные СУБД

Учитывая специфику колоночных СУБД, будет не эффективно ее использовать, если выборки достаточно простые, параметры выборки статичны, и если преобладают выборки по ключевым значениям. Так же, если количество строк в таблице, из которой делается выборка, меньше сотен миллионов строк, то скорее всего не будет большого преимущества, по сравнению с реляционной СУБД.

Нужно так же иметь ввиду, что в колоночных СУБД могут быть и другие ограничения. Например, может отсутствовать поддержка транзакций, а язык запросов может отличаться от классического SQL, и прочее.

Итоги

Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.

При выборе типа СУБД следует, прежде всего, исходить из типа решаемых задач, типов обрабатываемых данных, перспектив роста и масштабирования.

Обращайте так же внимание на популярность и наличие широкого круга разработчиков и средств разработки – это даст вам возможность, при необходимости, найти ответ на возникший вопрос быстро.

В данной статье я намеренно не делаю акцент на выбор между облачными и on-premise решениями - эта тема одной из следующих статей.

Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.

Тип СУБД

Когда выбирать

Примеры популярных СУБД

Нужна транзакционность; высокая нормализация; большая доля операций на вставку

Oracle, MySQL, Microsoft SQL Server, PostgreSQL

Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON

CouchDB, MongoDB, Amazon DocumentDB

Задачи подобные социальным сетям; системы оценок и рекомендаций

Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid

Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов

Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra

Надеюсь данная статья оказалась полезной.

В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.

В наше время базы данных используются везде, начиная от предприятий, где в них храниться различная производственная информация и имена сотрудников и заканчивая веб-сайтами. Большинство движков веб-сайтов хранят всю необходимую им информацию в базе данных и получают ее от туда. Такой способ работы намного быстрее, чем использование файлов для сохранения данных и намного надежнее, чем хранение данных в оперативной памяти.

За время развития технологий баз данных было создано много систем управления ими, моделей работы, а также программного обеспечения. В этой статье мы рассмотрим лучшие базы данных Linux, которые вы можете использовать в своих проектах. Вы сможете выбрать какое решение подойдет именно для вас и почему. Все пункты списка базы данных под Linux расположены в случайном порядке. Все базы данных из списка поддерживают стандарт ACID.

1. MySQL

Разработка базы данных MySQL началась в 1995 году, за это время над ней работали несколько компаний, и сейчас она принадлежит Oracle. Кроме версии с открытым исходным кодом, существует несколько коммерческих версий, в которых реализованы дополнительные возможности, такие как кластер гео-репликации и автоматическое масштабирование.

MySQL относиться к типичным реляционным базам данных, все данные хранятся в таблицах и приложения могут очень быстро получить к ним доступ. Для запросов используется стандартный язык SQL, поддерживается большинство возможностей языка, определенных стандартом. При всем этом, она легка в использовании и развертывании.

За время своего развития MySQL получила поддержку различных типов таблиц, интеграцию во многие программы и языки программирования, а также имеет веб и графические интерфейсы для настройки.

2. PostgreSQL

Postgresql появился приблизительно в то же время, что и MySQL. Это объектно-реляционная база данных с открытым исходным кодом, все данные представлены в виде объектов. В отличие от MySQL, эта база данных неукоснительно следует всем стандартам SQL из-за чего она может показаться более сложной. Она разрабатывается программистами со всего мира, а направление развития контролируется советом.

Postgresql поддерживает множество интересных возможностей, среди которых оптимизация запросов, репликация данных, курсоры, позволяющие передавать только часть данных приложению, тиггеры - события для запросов SQL, поддержка шифрования по умолчанию. Кроме того, можно создавать пользовательские типы данных, а также сама база интегрирована во множество языков программирования и приложений.

3. SQLite

База данных SQLite была впервые выпущена в 2000 году. Она работает не в форме клиент-сервер, как это делают большинство баз данных, а представляет из себя библиотеку, которая встраивается в приложение. Все данные хранятся в одном файле, на том компьютере, где запущена программа. Читать данные из файла могут несколько клиентов одновременно, но записывать только один и если других операций чтения не выполняется.

Благодаря компактности SQLite накладные расходы минимальны, а установка и использование очень просты. В то же время база данных соответствует большинству требований стандарта SQL. Поэтому SQLite используется по умолчанию во многих веб-фреймворках, и программах для рабочего стола, например: Mozilla Firefox, Skype, Thunderbird и многих других.

4. MariaDB

Эта база данных основана на исходном коде MySQL и ее разработка началась после перехода оригинала в собственность Oracle. За работу взялись первоначальные разработчики MySQL. MariaDB сохраняет тесную совместимость с MySQL, поддерживаются все ее команды и синтаксис запросов. Кроме того, из дополнительных возможностей можно отметить поддержку таблиц: XtraDB, Aria, PBXT, FederateX, OQGRAPH, SphinxSE и другие.

Кроме таблиц была очень сильно улучшена производительность и добавлены новые возможности. Разработка ведется компанией MariaDB Foundation и разработчиками по всему миру, но в развитие проекта инвестируют деньги множество компаний, среди которых Google и Intel. Это лучшая и самая популярная база данных Linux.

5. Percona

Percona DB - это сборка базы данных MySQL со включенным по умолчанию движком таблиц XtraDB. Этот движок основан на InnoDB но дает более высокую производительность и больше статистики.

Движок таблиц XtraDB основан на InnoDB, но включает патчи исправлений от компаний Google и Percona, поэтому дает большую производительность. Здесь улучшен механизм работы с памятью, скорость ввода/вывода, добавлена поддержка работы нескольких потоков и управление пропускной способностью. Вы можете не использовать отдельный сервер баз данных, а включить XtraDB в MariaDB или MySQL.

6. MongoDB

MongoDB - это не реляционная, документарная база данных, которая была выпущена в 2007 году. Основная ее особенность в том, что данные хранятся не в виде строк в таблицах, а в документах, в формате JSON. Запросы на получение и изменение данных тоже оформляются через JavaScript подобный язык.

Эта база данных не подходит для хранения реляционных данных, данных между которыми важны связи. Но она дает очень высокую скорость работы. Над разработкой проекта работают более 1000 партнеров. Дальше, снова базы данных sql.

7. Firebird

Firebird - это реляционная система управления базами данных, основанная на исходном коде базы данных Interbase, которая была выпущена компанией Borland в 2000 году. Поддерживаются все инструкции стандарта SQL 92 и почти все из SQL 99. Поддержка ACID реализована с помощью версий записи, каждый запрос работает со своей версией, а это значит, что ничего не блокируется и не мешает друг-другу. Из дополнительных возможностей поддерживаются тиггеры и процедуры хранения.

8. CUBRID

Это объектно-реляционная система управления базами данных, которая появилась в 2008 году. Она имеет особую архитектуру, специально оптимизированную для быстрой работы веб-приложений. За каждую задачу отвечает отдельный процесс, что дает преимущество в скорости. На данный момент поддерживается стандарт SQL 92.

База данных может интегрироваться со множеством языков программирования, среди которых PHP, Perl, Python и Ruby.

Выводы

В этой статье мы рассмотрели лучшие бесплатные базы данных Linux и других операционных систем, которые вы можете использовать в своих проектах. Все они имеют открытый код и распространяются полностью бесплатно, но каждая из них имеет свои преимущества. Какую базу данных вы используете в своих проектах? Почему именно ее? Напишите в комментариях!

На завершение вы можете посмотреть видео, о том, что такое базы данных:

Нет похожих записей

Оцените статью:

(15 оценок, среднее: 4,73 из 5)

Об авторе

Один комментарий

Как я Вас понимаю!
Я вот тоже много чем увлекаюсь, но времени на все увлечения яро е хватает. Поэтому я решил "выйти из мира теней информатики/интернета" и заняться простыми и обыденными вещами - применением узнанного/изученного в практике. Потому что просто изученный материал - это мертвые знания, которые практически никогда не пригодятся в реальной жизни.
Вот если взять те же базы данных - то важнее их применить для самого простого случая нужного каждой ДОМОХОЗЯЙКЕ например. Скажем сразу "сбацать" БД по нахождению вещей в хозяйстве - вот это будет польза в любой точке СНГ. А от БД с поиском вариантов нахождения студентов по аудиториям имеет крайне ограниченное применение - как образец у преподавателей информатики. Сразу "живой пример" - захотел я сделать 2-х полосные АС Салтыкова из ж.Радио. Настоящий инженер смотрит, что сделано до него и что можно сделать проще и лучше. Как это сделать? - Делать расчеты в "Электронных таблицах" как советуют гуру от акустики? Фига два. Написал я на борландовском Бэйсике программу для расчета АЧХ с визуализацией АЧХ, скомпилировал и получилось на 47Кб крошечная прога работавшая под ДОС, которая себя сразу и оправдала. Нужна была прога ля расчета многослойных катушек для фильтров - также написал. А что нам предлагают гуру? - Купить много не нужного ПО для решения минимальной задачи, принести много денег "гигантам IT" и стать бестолковыми юзверями.
Без сомнения СУБД нужны, но юзверя надо обучать СРАЗУ и быстро обучать с предложением СУБД или др. ПО. И не стоит "микроскопом забивать гвозди".

Забавно наблюдать за тем, как компьютерные технологии, которые, в момент их появления, кажутся необычными, в итоге либо уходят в небытие, либо становятся привычными и распространёнными. Например, в своё время, если на компьютере имелось больше одного пользователя, это иначе как «хай-теком» и назвать было нельзя. Были ещё и разработки, которые не завоевали широкой популярности, вроде векторных дисплеев, или памяти, адресуемой содержимым. А вот использование в компьютерах накопителей данных, особенно — жёстких дисков — стало весьма распространённой практикой. Но было время, когда накопители данных были экзотическими устройствами, пользоваться которыми было далеко не так просто, как в наши дни.

Меня, если говорить о накопителях данных, удивляет то, что понятие «файловая система», в том виде, в котором мы его знаем, за годы его существования изменилось не слишком сильно. Конечно, если сравнить то, что есть сейчас, с тем, что было, скажем, в 1960-е годы, то можно сказать, что в наши дни файловые системы дают нам гораздо более широкий функционал, чем прежде. В наши дни всё гораздо лучше в плане скорости, способов кодирования, шифрования, сжатия данных и так далее. Однако фундаментальная природа того, как мы храним файлы, и того, как с ними работаем в компьютерных программах, практически не изменилась. А всё должно быть не так. Нам известны более эффективные способы организации данных, но по каким-то причинам большинство из нас не пользуется этими возможностями в своих программах. Оказывается, правда, что пользоваться ими достаточно просто, и я собираюсь это продемонстрировать на экспериментальном приложении, которое вполне может стать отправной точкой разработки базы данных электронных компонентов для моей лаборатории.

Основой для базы данных, подобной той, о которой я хочу рассказать, может быть файл, где в роли разделителя данных применяются запятые (CSV-файл). Тут можно воспользоваться и чем-то вроде формата JSON. Но я собираюсь задействовать полномасштабную базу данных SQLite для того чтобы избежать необходимости в «тяжёлом» сервере баз данных и сложностей, сопряжённых с его поддержкой. Можно ли, используя мой подход, сделать что-то, что способно заменить базу данных, на которой основана какая-нибудь система резервирования авиабилетов? Нет. А подойдёт ли он для решения большинства задач, которые всем нам так или иначе приходится решать? Готов поспорить, что подойдёт.

Абстракция

Если подумать о файловых системах, то окажется, что это — не более чем абстракция над физическим устройством для хранения данных. Обычно мы не знаем или попросту не беспокоимся о том, где именно хранится нечто вроде файла hello.c . Нас даже не интересует то, сжат ли этот файл, то, зашифрован ли он. Он, возможно, был загружен по сети, а, может, его части хаотично разбросаны по всему жёсткому диску. Обычно нас это не волнует. А что если абстрагировать саму файловую систему?

Это, в общем-то, идея, лежащая в основе баз данных. Если имеется, например, список электронных компонентов, я могу сохранить его в CSV-файле и прочитать этот файл с помощью программы для работы с электронными таблицами. Или могу использовать полноценную базу данных. Проблема баз данных заключается в том, что для работы с ними обычно требуется некое серверное ПО, вроде MySQL, SQL Server или Oracle. Можно абстрагировать интерфейс базы данных, но это — весьма тяжеловесное решение, если сравнить его с простой операцией открытия файла и с обычной работой с этим файлом.

Правда, существует, например, популярная библиотека, называемая SQLite, которая даёт весьма надёжный механизм работы с базой данных, размещённой в единственном файле. При этом для работы с такой базой данных не нужен специальный сервер, её не нужно как-то по-особенному поддерживать. В работе с подобной БД, конечно, есть и ограничения. Правда, при её применении во многих простых программах можно пользоваться полезными возможностями баз данных, но при этом не тратить системные и финансовые ресурсы на поддержку инфраструктуры, обеспечивающей работу обычной СУБД.

Правильный инструмент для правильной работы

У SQLite, конечно, есть ограничения. Но если, например, некто занимается созданием собственного файлового формата для хранения неких данных, ему, возможно, стоит рассмотреть возможность перехода на SQLite и обработки этих данных средствами СУБД. В соответствии с данными, приведёнными на сайте SQLite, такой ход вполне может привести к экономии дискового пространства и к увеличению скорости доступа к данным. И ещё — после того, как программист освоится с этой технологией, окажется, что она упрощает работу с данными. И небольшое приложение, основанное на SQLite, если решено будет перевести его на что-то более серьёзное, лучше поддастся такому переходу.

Если вам надо хранить огромные объёмы информации, скажем — терабайты, или если надо, чтобы с данными одновременно могло бы работать много пользователей, особенно — если всем им надо писать данные в базу, то вам, возможно, это не подойдёт. На сайте SQLite имеется хорошая страница, на которой говорится об удачных и неудачных вариантах использования этой системы.

На стороне пользователей SQLite — возможность применения инструментов командной строки или их вариантов с графическим интерфейсом, вроде того, браузерного, который показан на следующем рисунке. Все эти инструменты позволяют работать с SQLite-базами данных без необходимости писать какой-то код.

В результате, например, можно решать задачи, вроде ввода данных в БД или исследования этих данных, и при этом совершенно не нуждаться в написании SQL-кода. Если же говорить о применении для похожих задач некоего собственного файлового формата, то, вероятно, решать эти задачи придётся вручную, или надо будет работать с данными, используя универсальные инструменты, которым ничего не известно об особенностях обрабатываемых с их помощью данных.

О моей задаче

Мне не хотелось бы тут рассказывать обо всём, что связано с разработкой приложения, я не собираюсь делать из этой статьи учебный курс по SQL — языку структурированных запросов, используемому в большинстве СУБД, включая SQLite. Мне, вместо всего этого, хочется показать то, как легко приступить к работе над простым приложением, применяющим возможности базы данных для хранения сведений об электронных компонентах, используя язык C. При этом написание кода на C будет представлять собой самую простую из наших задач. У нас есть две основных задачи, с которыми разобраться уже гораздо сложнее. Это — задача структурирования базы данных, то есть — проектирование схемы БД, и задача первоначального ввода данных в систему. Даже если БД планируется заполнять данными в процессе работы с программой, неплохо будет, если в самом начале в ней уже что-то будет, чтобы соответствующая программа с самого начала была бы работоспособной.

Основы работы с базами данных

В современных реляционных базах данных обычно имеется как минимум одна таблица. Их может быть и несколько. В каждой таблице имеются строки, в которых хранятся данные. Строки состоят из столбцов, которым назначены типы данных. Например, в таблице может присутствовать текстовый столбец, предназначенный для серийного номера электронного компонента. Ещё один столбец, предназначенный для хранения вещественных чисел, содержит сведения о напряжении в испытательной точке. А ещё один, хранящий данные логического типа, содержит значение, указывающее на то, пройдено испытание или нет.

Строки каждой таблицы имеют уникальные идентификаторы (ID). Если программист не предусмотрел механизм формирования этого ID, СУБД обычно может сама его сформировать. В частности, речь идёт об автоматическом инкрементировании подобных идентификаторов и об обеспечении того, что каждой строке таблицы будет назначен уникальный идентификатор.

Если бы возможности СУБД ограничивались тем, о чём я только что рассказал, то у них не было бы особых преимуществ перед обычными CSV-файлами. Но после того, как данные организованы вышеописанным образом, многие задачи можно решать лучше, чем при отсутствии такой структуры. Например, легко попросить систему выполнить сортировку элементов, или, например, выбрать из таблицы строки, содержащие три самых больших значения напряжения.

Надо отметить, что одной из главных сильных сторон баз данных является возможность создавать соединения данных. Предположим, у меня есть список компонентов ( Components ): печатная плата ( PCB ), резистор ( Resistor ), держатель аккумуляторной батареи ( Battery Holder ) и светодиод ( LED ). Имеется таблица, в которой для каждого из этих компонентов предусмотрена отдельная строка. Теперь представим, что у меня есть таблица с описанием сборных изделий ( Assembly ), сделанных из этих компонентов. Тут можно применить простой подход:

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

Используя операцию соединения данных можно скомпоновать эти таблицы и создать новую таблицу, хранящую сведения о том, сколько и каких компонентов нужно для некоего сборного изделия, не дублируя при этом слишком большого количества данных.

В результате я, в своей базе данных, планирую создать три таблицы. В таблице parts будет храниться список имеющихся у меня компонентов. В таблице partnums — сведения о типах компонентов (например — 7805, 2N2222 или CDP1802). И наконец — в таблице locations будут сведения о том, где именно хранится тот или иной компонент. Мои данные можно структурировать и по-другому. Скажем, может иметься таблица, в которой хранятся сведения о способах монтажа компонента. Например, компоненту 2N2222 может быть назначено значение TO92, или может быть указано, что он предназначен для поверхностного монтажа. Кроме того, я собираюсь создать механизм для просмотра данных, представление (view), в котором все данные будут показаны в развёрнутом виде — как в первом примере. Представление — это нечто такое, что в базе данных не хранится, но, для удобства, выглядит как таблица. А на самом деле это — всего лишь результат выполнения запроса к базе данных, с которым можно что-то делать.

Конечно, работа с БД этим не ограничивается. Существуют, например, внутренние и внешние соединения, имеется множество других деталей и нюансов работы с данными. Но, к нашему счастью, есть много хороших материалов о базах данных. Например — документация по SQLite.

Ровно столько SQL, сколько нужно для дела

Нам, для решения наших задач, понадобится сравнительно немного SQL-инструкций: create , insert и select . Имеется программа, sqlite3 , которая позволяет выполнять команды в применении к базе данных. Этой программе, средствами командной строки, можно передать имя базы данных, а потом можно работать с этой базой данных, что совсем несложно. Для выхода из программы используется команда .exit .

Вот команды создания таблиц базы данных. Полагаю, устроены они достаточно просто и понятно.

Я выполнил эти команды с помощью sqlite3 , в командной строке, но их можно было бы выполнить и из программы с графическим интерфейсом. А если бы мне это было нужно, я мог бы сделать так, чтобы они были бы выполнены из моей C-программы. Средства командной строки я использовал и для того, чтобы добавить в базу данных несколько тестовых записей. Например:

Для получения данных из базы используется команда select :

Если вы хотите глубже разобраться в этих и других командах — существует множество учебных руководств по SQL.

Программирование!

До сих пор мы, готовя основу программы, не нуждались, собственно, в программировании. При этом, исходя из предположения о том, что в нашем распоряжении имеется пакет наподобие libsqlite3-dev , для того чтобы оснастить C-программу функциями, направленными на работу с базой данных, нам не придётся прилагать особенно больших усилий. В частности, в коде нужно будет подключить sqlite3.h . Если такого заголовочного файла найти не удаётся — это может означать то, что в системе не установлено то, что нужно для SQLite-разработки. Ещё понадобится связь с libsqlite3 . Если говорить о простом однофайловом проекте, то, чтобы приступить к работе над ним, скорее всего, достаточно будет такого makefile :

Сам код очень прост. Сначала нужно открыть файл базы данных (с использованием функции sqlite3_open ). Вместо имени файла можно передать функции :memory . Тогда в нашем распоряжении окажется база данных, расположенная в памяти, которая будет существовать столько же времени, сколько будет работать программа. Этот вызов возвращает дескриптор базы данных. Далее — нужно подготовить SQL-запрос, который планируется выполнить. Это может быть запрос, подобный тем, которые мы уже выполняли, или — любой другой запрос. В моём случае мне нужно взять все данные из представления full и вывести их. Поэтому я собираюсь выполнить такой запрос:

И наконец — мы пользуемся функцией sqlite3_step . До тех пор, пока она возвращает SQLITE_ROW , мы можем обрабатывать строки, пользуясь функциями вроде sqlite3_column_text . В конце выполняется финализация и закрытие базы данных. Вот готовый код, из которого удалены механизмы обработки ошибок:

Если хотите — вот полный код. А в ситуации, когда перебор строк нас не интересует, можно воспользоваться функцией sqlite3_exec . Даже в документации говорится, что это — лишь обёртка вокруг функций prepare , step и finalize . Поэтому данной функции можно просто передать соответствующие входные данные и всё должно заработать.

Конечно, существует и множество других функций. Например, можно воспользоваться функцией sqlite_column_int , или, для получения других типов, можно применить другие вызовы. Можно прикреплять к SQL-вызовам параметры для установки значений, а не пользоваться строками. Здесь я лишь продемонстрировал то, насколько простым делом может быть создание программы, в которой используется SQLite.

Итоги

Когда вы в следующий раз поймёте, что занимаетесь выдумыванием нового файлового формата — поразмыслите о том, чтобы, вместо этого, воспользоваться SQLite. К вашим услугам будут свободные инструменты, а после того, как вы освоите SQL, вы поймёте, что можете сделать очень многое, не написав никакого программного кода, кроме, разве что, кода различных SQL-команд. Можно даже использовать систему для хранения разных версий базы данных, подобную той, что применяется в Git. И, кстати, некоторые используют в роли базы данных Git, но мы этого делать не рекомендуем.

Система управления реляционными базами данных Microsoft SQL Server имеет давнюю историю – идея продукта зародилась еще в середине 80-ых, а первая версия появилась в 1988 году. Его основой стал язык запросов Transact-SQL, созданный совместно Microsoft и Sybase. Стратегия дальнейшего развития Microsoft SQL Server приобрела цельный и завершенный вид в 2010 году. Тогда было объявлено, что SQL Server будет представлять собой единый продукт, реализуемый в настольных системах, в центрах обработки данных и в облаке (в 32- и 64- разрядном вариантах).

В числе приоритетных направлений — бизнес-аналитика (BI) и разработка соответствующих инструментов, развитие экосистемы облачных вычислений с переносом средств бизнес-аналитики в облако, расширение возможностей работы SQL Server Management Studio со средой SQL Azure. Значительное внимание было уделено вопросам масштабирования СУБД, виртуализации приложений в среде баз данных, а также пространственному представлению данных.

Эволюция Microsoft SQL Server. В последних версиях разработчики акцентировали внимание на обработке данных в оперативной памяти (in-memory) и работе с большими данными.

В качестве достоинства СУБД от Microsoft заказчики отмечают простоту внедрения, управления, программирования и обновления.

Microsoft SQL Server 2016

2016 год стал годом очередной смены версий – перехода с Microsoft SQL Server 2005 на Microsoft SQL Server 2016. Ее новые функции и усовершенствования обеспечивают более высокую производительность, усиленную безопасность и полноценные интегрированные возможности в области отчетности и аналитики. Это не радикальная «смена вех», но эксперты называют Microsoft SQL Server 2016 самым значительным обновлением за всю историю продукта. Он включает инструменты расширенной аналитики, машинного обучения, а также новые возможности для анализа и визуализации информации на любых устройствах.

Новая версия Microsoft SQL Server позволяет создавать критически важные приложения для оперативной обработки транзакций (OLTP) с улучшенной масштабируемостью, производительностью при выполнении в памяти и высокой доступностью. При этом обеспечивается согласованность локальной и облачной среды: SQL Server позволяет клиентам получать доступ к данным на локальных серверах и в облаке.

Перечислим некоторые ключевые особенности Microsoft SQL Server 2016:

С помощью SQL Server 2016 можно получать ценные сведения из транзакционных и аналитических данных в режиме реального времени. Продукт позиционируется как безопасная и масштабируемая платформа баз данных, которая предоставляет все необходимое — от расширенной аналитики до высокой производительности обработки любых нагрузок в оперативной памяти.

Оперативная аналитика в реальном времени позволяет быстрее принимать решения.

SQL Server 2016 работает значительно быстрее прежних версий: на том же оборудовании запросы выполняются примерно на 25% быстрее, а при использовании некоторых новых средств SQL Server 2016 с обработкой в памяти выигрыш достигает 30 раз для OLTP-транзакций и 100 раз для запросов (данные Microsoft). Однако и требования к аппаратному обеспечению в новой версии выросли.

Функциональные отличия разных редакций SQL Server 2016.

Функциональные возможности SQL Server 2016

Производительность	Выполнение OLTP в памяти
Хранение столбцов в памяти
Операционная аналитика в реальном времени
Регулятор ресурсов
Хранение запросов
Доступность	AlwaysOn
Расширенная поддержка визуализации и динамическая миграция
Безопасность	Постоянное шифрование
Прозрачное шифрование данных
Безопасность на уровне строк
Динамическая маскировка данных
Поддержка шифрования резервного копирования
Детальный аудит
Разделение обязанностей
Программируемость	Поддержка JSON
Запросы PolyBase для данных Hadoop
Temporal
Готовность к использованию в облаке	Stretch Database
Архивирование в Azure
Аварийное восстановление в Azure
Оптимизированные образы виртуальных машин в коллекции Azure
Управление	Распределенное воспроизведение
Управление на основе политик
Бизнес-аналитика	Усовершенствованные отчеты
Мобильная бизнес-аналитика
Сервисы интеграции, управляемые в качестве сервера
Закрепление отчетов в Power BI
Многомерные семантические модели
Усовершенствованные табличные семантические модели бизнес-аналитики
Сервисы основных данных
Сервисы качества данных
Расширенная аналитика	Расширенная аналитика в базе данных с помощью служб R Services
Многопоточная обработка запросов R и потоковая обработка в памяти

(красным выделены новые возможности, отсутствующие в SQL Server 2014).

В последние годы Microsoft расширила спектр своих предложений. Наряду с SQL Server в ее арсенале есть также Azure SQL Database («СУБД как сервис») и два облачных noSQL-решения — Azure DocumentDB и Azure Tables. В 2016 году корпорация Microsoft сделала еще один важный анонс — представила SQL Server для Linux. Ее платформа для управления данными и бизнес-аналитики стала еще более универсальной, расширив возможности для работы с данными и приложениями с применением разных инструментов, языков и систем в облачной, гибридной или локальной среде. Это еще один шаг в сторону упрощения SQL Server и повышения его доступности. Релиз этой версии ожидается в середине 2017 года.

Встречайте SQL Server для Linux

SQL Server для Linux, созданный на основе SQL Server 2016, предоставляет возможность разработки и развертывания интеллектуальных приложений на единой платформе для управления данными и бизнес-аналитики. Объявленная Microsoft поддержка операционных систем семейства Linux в новой версии SQL Server — очередной шаг корпорации по выходу на рынок Linux-систем после заключения партнерского соглашения с RedHat и Canonical.

C выпуском SQL Server для Linux разработчики получат широкие возможности выбора платформы для приложений, а пользователи виртуальных серверов (VPS) смогут развертывать SQL Server не только под Windows. Приложения SQL Server можно будет запускать в контейнерах Docker.

В частности, некоторые заказчики уже используют сервисы Azure Data Lake на Ubuntu. Теперь разработчики смогут создавать новые приложения со всеми возможностями SQL Server. А сотрудничество с Red Hat означает перенос SQL Server на платформу Red Hat Enterprise: заказчики получат еже более широкие возможности выбора ОС. На сайте SQL Server также уже появилась информация относительно новых возможностей СУБД.

Поэтому и поддержка ядра Linux не стала для отрасли неожиданностью. Microsoft не только еще раз продемонстрировала, что играет важную роль в движении Open Source. Выпуск SQL Server для Linux имеет целью расширение рынка: корпорация не желает упускать те 15% мирового рынка СУБД, которые занимают Linux-продукты Oracle и IBM. По данным IDC, Microsoft принадлежит более половины мирового рынка СУБД для Windows. Однако на других платформах лидирует Oracle, доля которой приближается к 50%.

По мнению аналитиков, решение Microsoft может быть выбрано не только в силу привлекательной стоимости, но и потому, что оно содержит ряд встроенных функций, которые отсутствуют в конкурирующих продуктах или предлагаются за дополнительную плату, и совместимо с Microsoft Excel .

Microsoft объявила, что заказчики бесплатно смогут приобрести лицензии на SQL Server при условии, что они решат отказаться от СУБД Oracle. «Перестаньте зависеть от Oracle. Перенесите свои базы данных Oracle на SQL Server и получите соответствующие временные лицензии SQL Server совершенно бесплатно вместе с Software Assurance», — призывает Microsoft на своем сайте. Корпорация даже разработала онлайн-тренинг: «Преобразование бизнеса путем перехода с Oracle на SQL Server».

Компания Canonical уже сделала SQL Server для Linux доступным в образах ОС Ubuntu, которую пользователи устанавливают в Microsoft Azure. Это позволяет им гибко использовать вычислительные ресурсы и недорогое дисковое хранилище. Такой вариант резко снижает общую стоимость платформы. Кроме того, в облачных средах ресурсы оптимизированы под рост рабочих нагрузок. Используя Docker и инструменты оркестрации Canonical, можно гибко наращивать производительность в соответствии с нагрузкой. Azure и контейнерные технологии в среде Linux позволяют реализовать сложные и высоконагруженные проекты без покупки дополнительного оборудования.

По данным опроса администраторов баз данных, Microsoft SQL Server уже используется в большинстве организаций.

Выпуск SQL Server для Linux означает, что Microsoft становится поставщиком кроссплатформенных решений. Ранее Microsoft уже перенесла свой Office и Office 365 на платформы iOS и Android. Такие продукты как Microsoft Intune и Azure AD также поддерживают разные устройства.

Проект Microsoft под кодовым наименованием Helsinki предполагает перенос SQL Server на несколько дистрибутивов Linux, включая Ubuntu, Red Hat Enterprise Linux и SUSE Linux Enterprise Server. Это логично дополняет и облачную стратегию корпорации — поддержку IaaS VM в Microsoft Azure для разных дистрибутивов Linux (CentOS, openSUSE, Oracle Linux, SUSE Linux Enterprise Server, Red Hat Enterprise Linux и Ubuntu). При покупке лицензий SQL Server (в расчете на сервер или на ядро процессора) заказчик сможет использовать одну и ту же лицензию в Windows Server и Linux. По программе Software Assurance можно бесплатно получать будущие версии продукта.

Конкурентный анализ рынка РСУБД за последние 30 лет показывает уверенный рост Microsoft SQL Server, особенно после выпуска SQL Server 2000. С поддержкой Linux этот рост мог бы быть еще значительнее. В настоящее время Linux, ПО виртуализации, контейнеризации, оркестрации, прикладные и связующие среды с открытым кодом играют важную роль в публичном облаке. Кроме того, по данным IDC, почти 40% серверов x86 продаются с ОС Linux и треть из них используются как серверы баз данных. Конечно, Microsoft SQL Server не станет продуктом с открытым исходным кодом, но, предлагая его как компонент стека Open Source, Microsoft существенно увеличит число инсталляций. Это серьезный вызов Oracle и IBM DB2 – также проприетарных СУБД для сред Open Source.

Каким он будет?

Следующая версия SQL Server под условным названием SQL Server v.Next предоставит экосистеме Linux возможности СУБД Microsoft, включая SQL Server Agent, аутентификацию в Active Directory, средства обеспечения высокой доступности и аварийного восстановления, безопасности и защиты данных. Предварительная версия SQL Server для Linux уже доступна для Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Ubuntu, а также облачных и контейнерных платформ, таких как OpenStack, Docker Swarm, Kubernetes и Mesosphere D/C OS.

Знакомьтесь: SQL Server для Linux. В него будут включены все основные средства SQL Server 2016.

SQL Server для Linux включает также такие средства SQL Server 2016 как хранение столбцов в памяти, что повышает производительность при выполнении запросов до 10 раз, In-Memory OLTP, благодаря чему скорость по сравнению с хранением таблиц на диске увеличивается до 2,5 раз. А Row-Level Security и Dynamic Data Masking защищают данные на сервере от несанкционированного доступа без внесения изменений в клиентские приложения.

При инсталляции SQL Server 2016 применяются стандартные для Linux методы: yum для дистрибутивов Fedora и apt-get для Debian. Поддерживается запуск по systemd, пути файлов Linux в операторах T-SQL и скриптах. Кластерами высокой доступности можно управлять с помощью таких популярных Linux-инструментов как Pacemaker и Corosync.

Microsoft предлагает также кросс-платформенные инструменты для SQL Server в Linux или Windows, такие как SQL Server Management Studio (SSMS), SQL Server Data Tools (SSDT), PowerShell (sqlps) и недавно анонсированное Visual Studio Code Extension для SQL Server. Поддерживаются также средства Microsoft Migration Assistant для переноса нагрузок. С помощью кросс-платформенных инструментов организации могут уже сейчас начать миграцию на SQL Server для Linux, а в 2017 году перейти на коммерческую версию v.Next.

Непрерывная интеграция и доставка (Continuous integration and continuous delivery, CI/CD) – практика DevOps, которая ускоряет внесение исправлений и изменений, позволяет выпускать продукты на рынок, повышать их качество и надежность.

Благодаря поддержке контейнеров в Windows и Linux ПО SQL Server будет работать под управлением оркестраторов Docker Swarm, Red Hat Open Shift, Mesosphere DC/OS и Kubernetes. С помощью Management Pack for SQL Server для Linux организации смогут использовать System Center Operations Manager для комплексного мониторинга – от аппаратных средств до экземпляров баз данных.

Поскольку SQL Server теперь доступен и для контейнеров, в разработке приложений можно применять некоторые практики DevOps, например, создать образ контейнера для использования в разных ОС. С помощью оркестраторов типа Docker Swarm или Red Hat Open Shift можно быстро обновлять контейнеры в тестовой и рабочей среде.

С выпуском SQL Server для Linux можно использовать базы данных в гетерогенной среде – как на собственных серверах, так и в виртуальных машинах в частных/публичных облаках и у провайдеров услуг VPS/VDS.

Читайте также: