Субд: какие бывают, как выбрать

Рекомендации по выбору СУБД

Реляционные СУБД (Oracle, MySQL, Microsoft SQL Server, PostgreSQL) универсальны и подходят почти для любых задач, когда не нужно обрабатывать очень большой поток запросов и хранить слишком большие объемы данных. Когда же запросов много, возникает проблема масштабирования, с которой реляционные СУБД пока нормально справиться не могут.

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

Если необходимо хранить связи между узлами в графовой структуре БД (например, в социальной сети для описания общих интересов или родственных связей) рекомендуем обратить внимание на такие СУБД как InfiniteGraph, Neo4j, Amazon Neptune и InfoGrid. Данное ПО позволит вам построить систему оценок и рекомендаций

В колоночных СУБД используется особый способ записи информации, благодаря чему менять структуру таблиц можно очень быстро. Этот тип БД рассматривает колонку как отдельную таблицу. Если в обычной реляционной СУБД считывание данных происходит по всей строке, пока не будет достигнута нужная колонка, в колоночной СУБД считывается сразу нужный столбец. Из преимуществ колоночных СУБД можно выделить хороший процент сжатия, что заметно уменьшает занимаемое пространство. Особенностью колоночных баз и колоночных индексов является то, что для них невозможна операция промежуточной вставки или апдейта. Часто эти базы не предусматривают оператор UPDATE, только DELETE и INSERT. Применять такие колоночные СУБД как SAP IQ, Vertica, ClickHouse, Google BigQuery, InfoBright для простой выборки со статическими параметрами, где хранится менее ста миллионов строк, не имеет смысла.    

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

Библиографический список

  1. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб.пособие / А.М. Вендров. – М.: Финансы и статистика, 2014 – 567 с.
  2. Информационные системы и технологии в экономике и управлении: учебник / под ред. проф. В.В. Трофимова.доп. – М.: Юрайт-Издат, 2011 – 280 с.
  3. Информационные технологии в управлении: Учебное пособие / О.Н. Граничин, В.И. Кияев – М.: Интернет-Университет Информационных технологий; БИНОМ. Лаборатория знаний, 2012 – 348 с.
  4. Информатика: Учебник / Под ред. проф. Макаровой Н. В. – М.: Финансы и статистика, 2010 – 362 с.
  5. Информационные системы и технологии в экономике: Учебник. – 2-е изд., доп. и перераб. / Т.П. Барановская, В.И. Лойко, М.И. Семенов, А.И. Трубилин; Под ред. В.И. Лойко. – М.: Финансы и статистика, 2015 – 266 с.
  6. Конгаловский М.Р. Энциклопедия технологий баз данных. – М.: Финансы и статистика, 2012 – 438 с.
  7. Карпова Т. С. Базы данных. Модели, разработка, реализация. – СПб.: Питер, 2002 – 389 с.
  8. Ковени М. Стратегический разрыв: Технологии воплощения корпоративной стратегии в жизнь М.: Альпина Бизнес Букс, 2006 – 379 с.
  9. Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник. – М.: Финансы и статистика, 2014 — 276 с.
  10. Практикум по информатике / А.А. Землянский, Г.А. Кретова, Ю.Р. Стратонович, Е.А. Яшкова; Под ред. А.А. Землянского. – М.: Колос, 2013 – 197 с.
  11. Риккарди Г. Системы баз данных. Теория и практика использования в Interner и среде Java. / ГрегРиккарди; пер. с англ. – М.: Издательский дом «Вильямс», 2001 – 492 с.
  12. Шпеник М., Следж О. и др. “Руководство администратора баз данных Microsoft SQL Server 10.0”, М., 2009 — 429 с.

Интернет ресурсы

  1. Базы данных и делопроизводство : URL: http://www.bdidp.amphyton.com/documentation/d6.html (дата обращения 13.02.2016 г.).
  2. Правовая система «Гарант» : URL: http://garant.ru/ (дата обращения 10.02.2016 г.).
  3. Официальный интернет-портал правовой информации : URL: http: // www. pravo. gov.ru(дата обращения 20.02.2016 г.).
  4. ИТ Капитал : URL: http://www.it-capital.info/crm/ (дата обращения 13.02.2016 г.).
  5. Общие понятия баз данных : URL: http://elhow.ru/programmnoe-obespechenie/chto-takoe-baza-dannyh (дата обращения 13.02.2016 г.).
  6. Базы данных : URL: http://www.studfiles.ru/preview/2585627/ (дата обращения 23.02.2016 г.).
  7. Понятие базы данных : URL: http://studopedia.ru/10_207009_ponyatie-bazi-dannih-vidi-modeley-dannih.html (дата обращения 23.02.2016 г.).
  8. Базы данных и СУБД : URL: http://flash-library.narod.ru/Ch-Informatics/lektion/lektion7.html (дата обращения 27.03.2016 г.).
  1. Токарев А.Н. Проектирование реляционных баз данных. (Методические указания к выполнению курсовой работы). // БФ РАНХ и ГС, Балаково, 2012.

  2. Информационно-справочный портал : URL: http: // support.office.com (дата обращения 04.05.2016г.)

  3. Базы данных и делопроизводство : URL: http://www.bdidp.amphyton.com/documentation/d6.html (дата обращения 13.02.2016 г.).

  4. Базы данных и СУБД : URL: http://flash-library.narod.ru/Ch-Informatics/lektion/lektion7.html (дата обращения 27.03.2016 г.).

  5. Конгаловский М.Р. Энциклопедия технологий баз данных. – М.: Финансы и статистика, 2012 – 148 с.

  6. Информационные технологии в управлении: Учебное пособие / О.Н. Граничин, В.И. Кияев – М.: Интернет-Университет Информационных технологий; БИНОМ. Лаборатория знаний, 2012 – 238 с.

  7. Информационно-аналитический портал : URL: http: // compress.ru/ (дата обращения 19.05.2016г.)

  • Технология клиент-сервер (Понятие технологии «клиент-сервер»)
  • Методы кодирования данных (Форматы данных )
  • Разработка регламента выполнения процесса Предоставление рекламных услуг
  • Внешняя и внутренняя среда организации (Характеристика внутренней и внешней среды ОАО «Johnson’s baby»)
  • Прогнозирование эффективности реальных инвестиций (Роль и значение инвестиций в экономике предприятия)
  • Оценка уровня конкуренции в отрасли (Оценка конкуренции в отрасли быстрого питания )
  • Проектирование реализации операций бизнес-процесса «Управление персоналом» ( Выбор комплекса задач автоматизации)(
  • «Управление рисками в проектной среде» . .
  • Место объектов патентных прав в системе объектов гражданских прав
  • Разработка конфигурации «Расчет заработной платы» в среде 1С:Предприятие 8.3. (Выбор комплекса задач автоматизации.)
  • Разработка проекта информационной системы учета сдельной оплаты труда
  • Основы алгоритмизации и программирования

Какие СУБД существуют и как их выбирать

Систем управления базами данных очень много. Но реально используют перечисленные ниже:

  1. Реляционные
  2. Key-value
  3. Документные
  4. Графовые
  5. Колоночные
  6. Time Series
  7. Spatial
  8. Search engines
  9. Объектные

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

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

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

Объём. В технической документации для каждой СУБД указаны лимиты на объём одного файла, таблицы и других объектов. В случае, когда нужно хранить большие массивы данных, заранее проверьте способность системы управления базами данных «переваривать» такие объёмы.

Нагрузка и масштабируемость

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

Ваша база данных может работать по сети и локально. От этого зависит выбор СУБД. Они бывают файловые и серверные.

Отказоустойчивость и безопасность. Для некоторых проектов отказоустойчивость — критично важный параметр. Что будет, если упадёт БД банка, объяснять не нужно. Поэтому ориентируйтесь на реальные потребности проекта в уровне отказоустойчивости СУБД. Аналогично и с безопасностью — сертификаты, шифрование, дополнительные возможности нужны для крупных проектов. Небольшому достаточно и менее «навороченной» СУБД.

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

Далее рассмотрим типы СУБД и их особенности.

Получить консультацию об облачных сервисахЗаказать звонок

Объектные

Данный тип СУБД предназначен для хранения и работы с объектами, у которых имеются свойства и методы. Основная задача таких СУБД заключается в избавлении разработчиков, использующих ООП, от необходимости трансформировать объекты в таблицы/строки и обратно. В объектных СУБД реализованы инкапсуляция и полиморфизм. Среди популярных СУБД этого типа можно назвать MongoDB Realm, InterSystems Caché, ObjectStore, Actian NoSQL DB, Objectivity/DB.

БД как сервис

  • MS SQL Web;
  • MS SQL Standard;
  • PostgreSQL (typical);
  • PostgreSQL (high availability);
  • MySQL (typical);
  • MySQL (high availability).


Тип СУБД


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


Популярные СУБД данного типа

1

Реляционные

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

Oracle, MySQL, Microsoft SQL Server, PostgreSQL, IBM DB2, SQLite

2

Ключ-значение

Задачи кэширования и брокеры сообщений

Redis, Memcached, etcd

3

Документные

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

Couchbase, MongoDB, Amazon DocumentDB

4

Графовые

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

Neo4j, Amazon Neptune, InfiniteGraph, TigerGraph

5

Колоночные

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

Vertica, ClickHouse, Google BigQuery, Sybase \ SAP IQ, InfoBright

6

Time series

Системы мониторинга, сбора телеметрии, и финансовые системы, с привязкой к временным меткам или временным рядам

InfluxDB, Kdb+, Prometheus, TimescaleDB, QuestDB, AWS Timestream, OpenTSDB, GridDB

7

Объектные

Высокопроизводительная обработка данных, имеющих сложную структуру, с использованием языков объектно ориентированного программирования

MongoDB Realm, InterSystems Caché, ObjectStore, Actian NoSQL DB, Objectivity/DB

8

Search engine

Системы полнотекстового поиска

Apache Solr, Elasticsearch, Splunk

9

Spatial

GIS-решения, работа с геометрическими объектами

Oracle Spatial, Microsoft SQL, PostGIS, SpatialLite

TurboDB

Сайт: http://turbodb.com

Немецкая СУБД – еще один коммерческий продукт. На сайте производителя представлено целых пять вариаций рассматриваемой СУБД, каждый из которых удовлетворяет своим требованиям: TurboDB for VCL 5.10, TurboDB Managed 1.4, TurboDB for .NET 5.10, TurboDB ODBC (Release Candidate) и TurboDB Studio 4.16. Для теста я выбрал Managed редакцию, полностью совместимую с .Net Framework 2.0 и Compact Framework 2.0.

Стоимость продукта — EUR 299.00 для индивидуальных разработчиков и EUR 499.00 для компаний. Любой из продуктов линии TurboDB можно скачать с сайта и бесплатно использовать в течении 30 дней.

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

Достаточно необычно организован менеджер БД. Изначально принципы его работы показались мне очень неудобными, потом же я понял, что основная его задача – безболезненная интеграция SQL-кода в приложение. Менеджер более эффективно справляется с отладкой SQL-запросов, чем с управлением структурой базы.

Как гласит документация, TurboSQL – подмножество SQL 92 и реализует минимальный набор функций, предусмотренных спецификацией MS ODBC. Именно в Managed редакции TurboSQL существенно расширился в основном за счет поддержки хранимых процедур и инструментов для работы с ними. Кроме того, сама база также полностью контролируется из кода приложения, что, собственно, вытекает из самого названия (Managed).

Показатели скорости обработки запросов TurboDB оказались вполне удовлетворительными. Особенно хороша TurboDB оказалась на select’e.

Сравнение SQL и NoSQL

Сейчас мы уже можем исследовать множество различных аспектов реляционных и нереляционных подходов к хранению данных. Пришло время сравнить их по разным показателям.

Масштабирование

SQL: масштабируется вертикально. То есть — путём увеличения производительности за счёт использования более мощных серверов. SQL-БД сложнее масштабировать, чем NoSQL-БД.

NoSQL: масштабируется горизонтально. То есть — путём добавления дополнительных узлов к уже существующим, использующимся узлам. Это упрощает масштабирование — при необходимости можно быстро как повысить, так и понизить мощность системы. Это, кроме того, означает, что владелец NoSQL-БД может увеличивать её мощность практически неограниченно.

Гибкость

SQL: эти БД не дают пользователю особой гибкости. Для работы с ними сначала надо спроектировать схему базы данных. А если в систему нужно внести какие-то изменения, например — добавить к записям новое свойство/столбец, придётся добавлять этот столбец к каждой строке. Это — ресурсозатратная и длительная операция.

NoSQL: эта технология даёт гораздо больше гибкости, чем её «старший брат». Здесь нет фиксированного количества столбцов, NoSQL-БД очень легко адаптируются к новым схемам данных. Программисту, кроме того, не нужно заранее создавать схему БД. Это ускоряет подготовку к работе систем, основанных на NoSQL. Правда, использование этой технологии может вылиться в дополнительные затраты времени в том случае, если для некоего проекта понадобятся достаточно жёсткие схемы данных.

Структура данных

SQL: данные хранятся в таблицах. Каждая сущность имеет собственную таблицу, они связаны друг с другом с использованием реляционных механизмов. Отсюда и термин — «реляционная система управления базами данных».

NoSQL: данные хранятся с использованием большего количества подходов, чем при использовании SQL-БД. В частности, доступны такие способы хранения данных, как база данных типа «ключ-значение», документоориентированная база данных, колоночная база данных, графовая база данных.

Набор требований, обеспечивающий сохранность данных

SQL: эти БД следуют требованиям ACID. ACID — это сокращение от Atomicity (атомарность), Consistency (согласованность), Isolation (изолированность) и Durability (надёжность).

NoSQL: эти БД следуют требованиям теоремы CAP. CAP расшифровывается как Consistency (согласованность), Availability (доступность) и Partition Tolerance (устойчивость к разделению).

Поддержка и сообщество

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

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

Сценарии использования

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

NoSQL: NoSQL-базы данных тоже можно назвать универсальными, но они по-настоящему раскрываются в приложениях, которые работают с разными источниками данных, имеющих различную структуру. Это могут быть IoT-приложения, игры и прочее подобное. Если рассмотреть варианты использования разных типов NoSQL-БД, о которых мы говорили выше, то получится следующее:

  • Документоориентированные базы данных: широкий круг задач.

  • Базы данных типа «ключ-значение»: обработка больших объёмов данных, где применяются простые запросы на поиск данных (например — управление сессиями в крупномасштабных системах).

  • Колоночные базы данных: обработка больших объёмов данных с предсказуемыми шаблонами запросов (работа с журналами, IoT).

  • Графовые базы данных: анализ и просмотр отношений между связанными данными (обнаружение мошенничеств, рекомендательные системы).

Субъективное сравнение СУБД

Следующая гистограмма (рис. 2) показывает, какой процент специалистов желает/избегает работать с конкретной СУБД.

Рис. 2. Объективная оценка удобства использования самых часто используемых СУБД.

Нереляционная СУБД Redis уже пятый год является самой любимой и востребованной СУБД, с которой удобно работать, как считают специалисты. Однако, реляционная PostgreSQL чисто символически уступает полпроцента. А такая мощная и весьма известная СУБД как IBM DB2 второй год подряд является системой, которую стремится избегать большинство.Кроме того, из практики авторы могут привести примеры практического внедрения и любопытные результаты.1) Переход с MS SQL на PostgreSQL (под Linux) оказался оправданным решением для высоконагруженных проектов (размер БД свыше 1 Тб). Это привело к повышению производительности, высвобождению ресурсов и упрощению обслуживания. В течение последних трёх лет данная тенденция остаётся неизменной. 2) Переход с MariaDB на MySQL полностью оправдывает себя, что показали примеры с несколькими веб-сайтами. Несмотря на то, что непосредственно перенос БД в другую СУБД зачастую оказывается непростым мероприятием, дальнейшая простота в обслуживании и стабильность явно того стоят.3) Дополнительное кэширование средствами Redis может дать десятикратный прирост производительности для старого высоконагруженного сайта.Из авторской практики следует привести в качестве примера один из интересных вариантов выбора и внедрения. В одном из проектов для полнотекстового поиска был применён Redisearch (надстройка над Redis), и через какое-то время стал очевидным недостаток — для Redis работает правило, что все данные должны храниться в ОЗУ. В результате пришлось менять структуру проекта и использовать ElasticSearch, благо у него более мощный язык поиска данных и репликация реализована без дополнительных настроек.4) Ещё интересный случай из авторской практики: на самом старте проекта была применена СУБД MongoDB без шардирования, а с развитием проекта оказалось, что производительности начинает не хватать. Возникла необходимость выбирать критерии шардирования. Выбор был сделан вынужденно неоптимально, т.к. к этому моменту БД успела вырасти до неудобных размеров (8 Тб). Был сделан вывод о том, что подобными вопросами следовало озаботиться при дизайне системы.5) Наконец, из опыта авторов следует упомянуть интересную ситуацию использования базовых возможностей СУБД, которые показали себя максимально эффективно. В одном из проектов была применена СУБД MongoDB в базовом варианте репликации на 3 копии. Когда произошёл серьёзный аппаратный сбой и была физически уничтожена треть кластера, на работоспособности всей системы это не сказалось ни коим образом.

Что такое система управления базами данных (СУБД)

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

Помогаем

Собираем на дрон для штурмовиков Николаевской области. Он поможет найти и уничтожить врага

Колоночные

Колоночные БД отличаются от реляционных тем, что информация в них хранится столбцами, а не построчно. Значение атрибута любого из объектов прочитывается сразу. Используются они в качестве хранилищ данных с большим (от ста миллионов записей) объёмом информации, и при обработке скромных объёмов не способны продемонстрировать свои преимущества.

Колоночные СУБД удобны тем, что позволяют действительно быстро выполнять сложные аналитические запросы на больших объёмах данных. При этом структура таблиц с данными легко меняются, а эффективная компрессия позволяет экономить занимаемый БД объём памяти. Среди популярных СУБД этого типа можно назвать Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra, SAP IQ.

СУПБД (система управления пространственными базами данных)

Этот тип СУБД оптимизирован для работы с объектами, определенными в геометрическом пространстве — как простыми (точки, кривые, многоугольники), так и сложными (3D-объекты, топологическое покрытие, линейные сети).

СУПБД ​имеет набор специальных функций для обработки создания, преобразования, измерения (расстояние, площадь, объем), вычисления (пересечение/контакт) и выбора на основе определенных критериев. И содержит специальные индексы, оптимизирующие обработку объектов, и особый стандартизированный язык SQL/MM.

Самые известные СУПБД:

  • Oracle Spatial;
  • Microsoft SQL;
  • PostGIS;
  • Spatiallite.

Когда следует выбирать СУПБД?

При создании ГИС-решений — не только для хранения, но и для работы с геометрическими объектами на уровне СУПБД.

Когда не следует выбирать СУПБД?

Для хранения геометрических объектов в качестве координат.

Столбцовая СУБД

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

Реляционная СУБД хранит данные построчно. То есть для считывания значения конкретного столбца приходится считывать почти всю строку — от первого до этого столбца.

Столбцовая СУБД хранит данные по столбцам. То есть столбец предстает в виде отдельной таблицы. А считывание выполняется прямо из конкретного столбца. На самом деле работает очень быстро — протестировано на нескольких реализованных хранилищах данных.

Преимущества столбцовой СУБД:

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

Самые известные столбцовые СУБД:

  • Sybase IQ (SAP IQ);
  • Vertica;
  • ClickHouse;
  • Google BigQuery;
  • InfoBright;
  • Apache Druid.

Когда следует выбирать столбцовую БД?

1) При создании хранилища данных и осуществлении выборки со сложными аналитическими вычислениями. 2) Когда количество запрашиваемых строк превышает сотни миллионов.

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

1) Когда количество строк в таблице, из которой делаются запросы, меньше сотен миллионов. Здесь у столбцовой СУБД перед реляционной преимуществ будет немного.

2) Когда запросы достаточно простые и со статичными параметрами. В этом случае — учитывая специфику системы — столбцовая СУБД будет неэффективна.

Объектные СУБД (Object-oriented)

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

Яркие представители этого типа СУБД: MongoDB Realm, InterSystems Caché, ObjectStore, Actian NoSQL DB, Objectivity/DB.

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

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

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

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

3.1. Интерфейс ввода/вывода данных

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

Главная форма базы данных «Промэнерго» содержит в себе «шапку» с эмблемой организации, и названием организации, так же форму навигации в которой при первом открытии открываеться страница «заказы» в которой содержатсяь оинформация о заказе;

  • Код заказа
  • Фио заказчка
  • Наименование товара
  • Метраж заказа
  • Дата заказа
  • Индикатор окончания работы

Главная форма представленна на рисунке «2»

Рис 2 «Главная форма»

Присутсвует два окна в правом-инфомрация находящиеся в разделх, а в левом расположенные кнопки перехода на разделы:

Заказы

Запрос на информацию о клиенте рисунок «3»

Рис 3 «Запрос на информацию о клиенте»

В данной форме можно узнать информацию о клиенте и его заказе по ФИО клиента или номеру заказа при вводе конкретной информации вы переходите на вкладку клиент и получаете полную информацию. Рисунок «4»

Клиент

в данной вкладке мы видим код клиента, ФИО заказчика и его контакный телефон, так же можно посмотреть код заказа и конкретные наименования товаров и время их заказа.

Рис 4 «Клиент»

Производство

Вкладка производство рисунок «5» позволяет оператору узнать сколько какого товара находиться на складе, сколько в монтаже и оперативно контролировать наличие товара.

Рис 5 «Производство»

Рабочие

Вкладка Рабочие показана на рисунке 7

На ней указана контактная информация о рабочих;

  • Код работника
  • Фамилия Имя Отчество
  • Адрес проживания
  • Телефон
  • Номер бригады
  • Должность работника

Рис 6 «Рабочие»

Итоги

Благодарю всех, кто добрался до этого места. Мы поговорили о том, что собой представляют базы данных, исследовали возможности и варианты использования баз данных SQL и NoSQL, разобрали их ключевые различия.

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

Я совершенно уверен в том, что каждый из этих подходов отлично показывает себя в своей сфере. То есть — в общих сравнениях, в словах о том, что «одно лучше другого», смысла нет. Всё зависит от конкретной ситуации.

Надеюсь, вы нашли эту статью информативной и подробной, что вам легко было её читать. Спасибо и до новых встреч!

Рейтинг
( Пока оценок нет )
Editor
Editor/ автор статьи

Давно интересуюсь темой. Мне нравится писать о том, в чём разбираюсь.

Понравилась статья? Поделиться с друзьями:
Работатека
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: