Как написать свою субд

Введение

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

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

Зачем создавать собственную базу данных

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

1. Данных становится очень много

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

2. Становится трудно находить нужную информацию

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

Кроме потери времени, эти поиски постоянно мешают вам в решении важных задач.

3. Необходимо делиться информацией или работать с ней совместно

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

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

Этапы создания собственной базы данных

Весь процесс создания базы данных можно разбить на 4 этапа.

1. Анализ и выработка требований к базе данных

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

2. Выбор инструментов создания базы данных

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

3. Создание структуры базы данных

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

4. Наполнение базы данных

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

Инструменты для создания базы данных

Можно выделить 4 основных типа инструментов для создания собственной базы данных:

  • табличные редакторы;
  • файловое хранилище;
  • классические СУБД;
  • онлайн-базы данных.

Постараемся разобраться в сфере применения, в плюсах и минусах этих инструментов.

Табличные редакторы

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

Это очень мощный инструмент для работы с данными, и многие его используют для создания своих баз данных.

Современный табличный редактор, такой как MS Excel, имеет удобный интерфейс, огромное количество функций, возможность создавать простые интерфейсы, специализированный язык программирования.

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

Также стоит отметить, что в последнее время всё более популярными становятся онлайн-табличные редакторы, такие как Google Sheets, Smartsheet и т. д. Их функциональность пока уступает классическим табличным редакторам, но по удобству и доступности они уже во многом их превосходят.

Ограничения

  • В табличных редакторах очень трудно создать жесткую структуру данных. В таблицах четыре основных структурных элемента — листы, строки, столбцы и ячейки. Когда вы начинаете создавать документ, то наделяете эти элементы определенным смыслом и тем самым создаете структуру данных, связи и ограничения. Но вы это создаете у себя в мозгу. Сама программа не знает, что ячейки одной строки связаны между собой и описывают один конкретный объект, что в некоторых ячейках находятся данные, а в других — названия столбцов.
    И такая вариативность, и гибкость хороша, когда у вас небольшой объем несложных по структуре данных и вы не работаете над данными совместно.
  • Табличные редакторы не предназначены для работы с большим количеством данных. Когда у вас несколько тысяч записей, проблем, как правило, не возникает, но с ростом количества записей с такой таблицей становится трудно работать. Кроме того, значительно повышается риск случайной порчи или удаления данных. Достаточно один раз неудачно отсортировать их, и вы можете полностью потерять целостность данных.
  • Трудно связывать данные. Если у вас есть несколько таблиц и данные в них логически связаны, то нужно их объединять и в самом редакторе. Это можно сделать, но потребуются определенные усилия и жесткий контроль за содержимым всех участвующих в связях ячейках и листах. Ибо достаточно сделать несколько неправильных изменений, и вы можете потерять важную информацию.
  • Совместная работа. Изначально таблицы предназначались в основном для однопользовательского применения. Сейчас современные онлайн-редакторы позволяют работать совместно. Но дав доступ на изменение данных, вы со временем можете обнаружить, что важные данные были искажены или удалены и это опять может быть связано с тем, что другие люди неправильно поняли их структуру и как данные связаны.

Файловое хранилище

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

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

При этом структура хранения информации создается с помощью иерархии папок и стандартизированных имен файлов, например: тип документа, номер документа, дата документа или дата съемки, место съемки.

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

Ограничения

  • Поиск. Как правило, поиск вы можете проводить только по имени файлов, по тем фразам, которые находятся в нём. И тут возникает 2 проблемы.
    Первая проблема — ограничение длины имени файлов в файловой системе. Вы просто не сможете создать длинное описание файлов.
    Вторая проблема — вы сможете проводить только очень простой поиск файлов по фразам, находящимся в их названии, и не сможете проводить сложные выборки на основе нескольких параметров поиска. И если при персональном использовании и небольшом количестве файлов можно попытаться это сделать простым просмотром содержимого папок, то в базах данных уровня компании это будет просто физически невозможно.
  • Доступность. Если вы используете файлы только внутри организации, то проблем с доступностью не должно быть. А если нужно получить доступ к информации по сети «Интернет», например, из дома, или нужно дать доступ к вашей информации сторонней организации, то в случае внутрисетевого хранилища, это будет очень затруднительно. При использовании облачного хранилища проблем не должно быть.
  • Совместная работа и настройка прав доступа. Просто выкладывать все файлы на файловый сервер и предоставлять к ним доступ всем не совсем правильно и рискованно. Нужно обязательно администрировать доступ к информации как на уровне папок, так и доступных пользователям действий. И тут необходимо привлекать IT-специалистов. Кроме того, контролировать изменения в структуре и файлах тоже сложно.
  • Бэкап. Нельзя забывать и о резервировании информации, так как, к сожалению, срок службы жестких дисков на вашем компьютере или сервере не бесконечен. И эта задача ложится полностью на вас или ваших IT-специалистов.

Классические СУБД

Классические СУБД — это самое мощное и гибкое решения для создания баз данных.

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

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

Но, как вы понимаете, идеальных решений не бывает, и у такого подхода есть свои недостатки.

Ограничения

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

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

Время. На разработку интерфейса потребуется время. И как часто бывает, времени потребуется существенно больше, чем будет изначально запланировано.

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

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

Конструкторы онлайн-баз данных

Конструкторы онлайн-баз данных появились значительно недавно и стали возможны благодаря появлению современной и недорогой облачной инфраструктуры (amazon aws, google cloud, ms azure) и развитию технологий построения многофункциональных web-интерфейсов.

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

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

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

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

Основными преимуществами конструкторов баз данных являются:

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

Но и тут, конечно, есть свои ограничения.

Ограничения

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

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

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

От чего зависит выбор решения

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

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

Но я бы дал следующие советы:

  1. Если вы собираетесь хранить структурированные данные небольшого объема и в основном для личного использования, то, я думаю, стоит выбрать табличный редактор.
  2. Если вам нужно хранить исключительно файлы и использовать их совместно с небольшим количеством людей, понимающих и соблюдающих структуру и правила наименования файлов и папок, то стоит выбрать файловое хранилище.
  3. Если вам нужна специализированная база данных и сделанный под вас интерфейс со множеством уникальных функций, тесно увязанная с вашими бизнес-процессами и другими используемыми системами, то вам необходима классическая база данных и заказная разработка интерфейса.
  4. Если вам нужна, с одной стороны, понятная и простая многопользовательская база данных, а с другой, — обладающая основными функциями и возможностями классических баз данных, то стоит посмотреть в сторону конструкторов онлайн-баз данных.
    Также конструктор подойдёт в том случае, если вы не определились с выбором инструмента создания базы данных. Начав её делать в конструкторе, вы легко сможете впоследствии мигрировать на другое решение.

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

Хочу еще выделить пару важных моментов, о которых стоить помнить при создании базы данных.

Неправильные требования

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

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

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

Может так оказаться, что те же недорогие конструкторы баз данных готовы покрыть 80-90% ваших требований и оставшиеся 10-20% не стоят тех денег и усилий, которые потребуются для их реализации. Также не стоить забывать, что сейчас так всё быстро меняется, что к тому времени, как вы реализуете 100% нужного вам функционала, сама задача может уже коренным образом измениться.

Плохое юзабилити

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

А именно от правильного юзабилити во многом зависит эффективность работы с создаваемой базой данных.

Плохо проработанный интерфейс приводит к дополнительным потерям времени на обучение сотрудников и работу с самой базой данных.

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

И тут могут возникнуть проблемы с удобством интерфейса и производительностью ввода данных.

Чем меньше времени вы будете тратить на ввод данных, поиск, изменение, тем больше эффекта вы получите от использования своей базы данных.

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

Тратя лишнее время на ввод данных, вы теряете его, а значит, упускаете и свои деньги.

Заключение

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

Как написать свою СУБД

Автор Сообщение
 

СообщениеДобавлено: 19.07.2006 15:17 

[профиль]

Member

Статус: Не в сети
Регистрация: 01.03.2006
Откуда: БССР

Привет, оверы.

Вот, есть проблема: нужно написать СУБД, которая удовлетворяла бы следующим условиям:

1. однопользовательская

2. многозадачная

3. не требовательная к ресурсам

4. структура данных должа легко обновляться (ключевой вопрос)

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

Просмотрел много форумов, посвященных программированию, а подходящих советов не нашел.

Жду ваших советов.


_________________
Измеряй микрометром. Отмечай мелом. Отрубай топором

http://L-B-H.org

Реклама

Партнер
 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

John Mirro

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

PS: А зачем требуется писать свое, если есть огромное множество уже написанных?


_________________
Sapienti sat

 
John Mirro

Member

Статус: Не в сети
Регистрация: 01.03.2006
Откуда: БССР

—Vel— писал(а):

выполнять лишь десяток базовых операций

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

—Vel— писал(а):

А зачем требуется писать свое, если есть огромное множество уже написанных?

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


_________________
Измеряй микрометром. Отмечай мелом. Отрубай топором

http://L-B-H.org

 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

John Mirro

John Mirro писал(а):

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

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

John Mirro писал(а):

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

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


_________________
Sapienti sat

 
John Mirro

Member

Статус: Не в сети
Регистрация: 01.03.2006
Откуда: БССР

Язык можно С/С++ или Дельфи/Паскаль.


_________________
Измеряй микрометром. Отмечай мелом. Отрубай топором

http://L-B-H.org

 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

John Mirro Если использовать Delphi, то могу посоветовать в качестве СУБД использовать Interbase/Firebird. Они писались, если мне не изменяет память, специально под Borlandовские среды разработки. Плюс использования этих СУБД в том, что сам сервер базы вкомпиливается в программу и не нужно будет ничего ставить дополнительно (просто рядом с программой будет лежать дополнительная dll с самим движком сервера). Минус — это действительно будет только однопользовательская СУБД, более того, локальная. Если это подходит — в Google.

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


_________________
Sapienti sat

 
John Mirro

Member

Статус: Не в сети
Регистрация: 01.03.2006
Откуда: БССР

—Vel—

С Interbase/Firebird я очень хорошо знаком, однако из-за специфики задачи он не подходит. А именно: по сути, программа является каталогизатором деталей/запчастей и т.д. с возможностью поиска. Пользователь может создавать любое количество разных каталогов и все они должны быть отдельными файлами, которые должны ассоциироваться с программой (как любой документ-кликнул по нему, программа открылась).

Конечно, можно сделать это в интербейс/фаерберд, но вот размер пустой базы данных сам занешь какой :) А если менять структуру данных, а у пользователя будет несколько десятков каталогов. В интербейсе это будет гиморно. Я думаю ты понял проблему.


_________________
Измеряй микрометром. Отмечай мелом. Отрубай топором

http://L-B-H.org

 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

John Mirro

Что собой будет представлять каталог? Будет ли это просто таблица фактов, или же каждый каталог — это полноценная база?


_________________
Sapienti sat

 
John Mirro

Member

Статус: Не в сети
Регистрация: 01.03.2006
Откуда: БССР

—Vel—

Каждый каталог-полноценная база данных


_________________
Измеряй микрометром. Отмечай мелом. Отрубай топором

http://L-B-H.org

 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

John Mirro

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

Используем в качестве СУБД DBISam. Это локальная СУБД, каждая таблица хранится в двух/трех отдельных файлах. Каждый каталог будет из себя представлять реальную папку на диске. Насколько я понял постановку задачи, структура базы фиксирована. В таком случае, при работе в другим каталогом просто меняется путь к базе. Теперь по поводу одного файла и его ассоциации с приложением. Есть идея просто заархивировать каждый каталог в отдельный файл без сжатия с со своим расширением (благо модули работы с тем же Gzip есть практически под все среды разработки, так что архиватор есть). Когда пользователь будет кликать на файл, программа запускается, распаковывает содержимое в одну из своих рабочих папок. Когда работа заканчивается, содержимое рабочей папки обратно собирается в один «архив» и перезаписывает предыдущую версию. Все это довольно громоздко и содержит подводные камни, но, по-моему, на много порядков проще, чем писать собственную СУБД


_________________
Sapienti sat

 
John Mirro

Member

Статус: Не в сети
Регистрация: 01.03.2006
Откуда: БССР

—Vel—

Вариант интересный, стоит подумать.


_________________
Измеряй микрометром. Отмечай мелом. Отрубай топором

http://L-B-H.org

 
Zio

Member

Статус: Не в сети
Регистрация: 29.10.2003
Откуда: 埼玉、日本
Фото: 4

John Mirro

не проще ли написать прогу и прикрутить к ней opensource-движок (например, postgresql).

 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

Zio

Не проще. Тот же PostreSQL требует отдельного сервера. Если же задаться целью локального использования native Win PostrgeSQL, то с той же самой инсталяцией приложения будут огромные трудности (нужно будет установить и настроить сервер). Плюс теряется переносимость каталогов с одного компьютера на другой (бекап/рестор из консоли или фронтэнд вряд ли простой пользователь осилит)


_________________
Sapienti sat

 
force_sk

Member

Статус: Не в сети
Регистрация: 10.03.2004
Откуда: Минск

А почему нельзя просто использовать Microsoft Access? С приложением поставляться должны будут просто файлики с самими данными. Сервер не требует для работы. У меня в связке с приложение на C# замечательно работает. Никто не жаловался.

 
gsvZolo

Member

Статус: Не в сети
Регистрация: 25.06.2005
Откуда: Zolotonosha

force_sk писал(а):

А почему нельзя просто использовать Microsoft Access?

Я бы писателей баз данных на Microsoft Access просто :gun:, ни одного толкового приложения не видил, одни геморройные недоразумения.


_________________
Наша работа настолько грязная, что делать её могут только истинные джентльмены.

 
—Vel—

Advanced member

Статус: Не в сети
Регистрация: 12.01.2004

gsvZolo

gsvZolo писал(а):

Я бы писателей баз данных на Microsoft Access просто

Ну не нужно так грубо, Access очень полезен в некоторых сферах
force_sk

force_sk писал(а):

А почему нельзя просто использовать Microsoft Access?

Довольно хороший вариант. Но, в случае, если нет ограничений на установку OBDC (W2K, к примеру, не имеет нативной поддержки Access, точнее, драйвера под него) и, если хранить именно файлы баз, то трудно будет настроить ассоциации в некоторых случаях + базы будут видны всем.

Если же эти пункты не являются препятствием, то, повторюсь, очень толковое решение


_________________
Sapienti sat

 
force_sk

Member

Статус: Не в сети
Регистрация: 10.03.2004
Откуда: Минск

gsvZolo Очень зря ты так. Я тоже раньше как-то недолюбвивал Access (просто не юзал его, а только слышал), а потом пришлось именно их и использвоать. И нормально прошло. Работает.

 
gsvZolo

Member

Статус: Не в сети
Регистрация: 25.06.2005
Откуда: Zolotonosha

force_sk

Извиняюсь конечно, могу и ошибаться, но это всё из жизненного опыта. :), почему бы просто не взять готовую СУБД например тот же банальный Fox, намного мощнее и менее глючно, чем Access.


_________________
Наша работа настолько грязная, что делать её могут только истинные джентльмены.

 
force_sk

Member

Статус: Не в сети
Регистрация: 10.03.2004
Откуда: Минск

gsvZolo Если честно, с Fox не работал и особо про него ничего не знаю, так что тут посоветовать не могу.

 
Ray Adams

Advanced member

Статус: Не в сети
Регистрация: 09.06.2003
Откуда: USSR

Зачем заниматься извращениями!??? Базы от Access прекрасно подходят для такого дела. Они не глючат. Глоючат руки у программеров, не умеющих использовать правильно эту систему. Для твоей задачи это просто идеальный вариант!

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Лаборатория

Новости

I have taken a graduate level course which is just one big project — to write a DBMS.

The objective is not to reinvent the wheel and make an enterprise DBMS to rival Oracle. Only a small subset of SQL commands need to be supported. Nor is the objective to create some fancy hybrid model DBMS for storing multimedia or something. It has to be a traditional RDBMS.

The main goal of the project is to use programing techniques to take advantage of modern architectures (multicore processors) to build a high performing database (speed, load).

I was just wondering if there were any resources on query evaluations, optimizers, data structures ideal for DBMSes or basically anything that could help me create a standout project. The professor was throwing around terms like metaprogramming for example.

The project must be done entirely in C++.


Thanks for the replies so far! I cannot optimize an existing DBMS such as MySQL as the project requires you to build your own DBMS from scratch. Yes I know this is pretty much reinventing the wheel for most part, but there is scope for some novel query evaluation and optimization algorithms. If you know any good resources or books dealing with this specific area, then please tell me!

Bill the Lizard's user avatar

asked Jan 9, 2010 at 1:18

user245120's user avatar

2

First you need to learn about relational calculus and make a compiler to deal with making it from sql, thankfully sql is an easy language and this is not bad.

Then get familiar with bx-trees for your indexes. Then make a commit and rollback space and that is pretty much all there is to it. It’s not rocket science, compared to other projects you might undertake, but it’s definitely something you better start right away if you want a good result by the end of the semester/year.

edit: Oh, and as for modern architecture goes, trees don’t usually benefit much from multithreading. Neither do disk reads. On the other hand, it’s crucial for high performance to use the whole of your memory using OS level calls, not just the memory normally addressable in a process.

answered Jan 9, 2010 at 10:37

Charles Eli Cheese's user avatar

As your looking to take advantage of modern CPU architectures, it might be worth looking at the MonetDB project. The project has produced a lot of research around optimising databases for modern CPU architecture, using column stores and storing compressed pages in memory — only decompressing them in the CPU cache to get significant speeds for very large databases.

This approach (column oriented storage + compression) and a more traditional query engine, perhaps based on the SQLite engine, should be a good basis for a project.

answered Jan 9, 2010 at 17:42

Robert Christie's user avatar

Robert ChristieRobert Christie

19.9k8 gold badges42 silver badges37 bronze badges

1

Since your professor mentioned metaprogramming, you might want to look at the following:

  1. WAM — Warren Abstract Machine. This compiles prolog code into a set of instructions that can be executed on an abstract machine. The idea is similar to jvm and cli. You don’t need to go into this in detail, just understand the idea of an abstract machine.

  2. JVM, CLI — same as above.

  3. Tools such as lex, yacc, flex, bison. Since you will be writing essentially an interpreter/compiler for SQL commands, you probably want to use some tools. This can be viewed as a form of metaprogramming, since you are using a language to write a tool — so you are programming at the meta-level.

  4. Again, the idea of meta-programming — perhaps you can augment your language with constructs that will allow your SQL compiler/interpreter to automatically optimize for parallel queries. These can be implemented as hints etc. to the compiler.

  5. Recompilers — you might want to write an interpreter/compiler that recompiles the initial queries into ones that can run in parallel for your target architecture. For example, for an N-core architecture, it might recompile a query into N-subqueries that execute in parallel, then combine the results.

I’m not sure that you should go into a great deal of research into standard optimization practices. These can be complex, and the subject of a lifetime of research in themselves. Since the object of the exercise is to take advantage of parallel processing, and meta-programming, that should be the focus of your research.

answered Jan 9, 2010 at 17:53

Larry Watanabe's user avatar

Larry WatanabeLarry Watanabe

10.1k9 gold badges42 silver badges45 bronze badges

1

Except for proprietary issues, how about optimizing MySQL in such ways? This is no trivial task though. Query optimization which takes advantage of parallel processing might be an entire term’s work.

It’s better to stand on the shoulders of giants to reach upward than to stand beside them.

answered Jan 9, 2010 at 1:23

wallyk's user avatar

wallykwallyk

56.4k16 gold badges85 silver badges147 bronze badges

5

I have taken a graduate level course which is just one big project — to write a DBMS.

The objective is not to reinvent the wheel and make an enterprise DBMS to rival Oracle. Only a small subset of SQL commands need to be supported. Nor is the objective to create some fancy hybrid model DBMS for storing multimedia or something. It has to be a traditional RDBMS.

The main goal of the project is to use programing techniques to take advantage of modern architectures (multicore processors) to build a high performing database (speed, load).

I was just wondering if there were any resources on query evaluations, optimizers, data structures ideal for DBMSes or basically anything that could help me create a standout project. The professor was throwing around terms like metaprogramming for example.

The project must be done entirely in C++.


Thanks for the replies so far! I cannot optimize an existing DBMS such as MySQL as the project requires you to build your own DBMS from scratch. Yes I know this is pretty much reinventing the wheel for most part, but there is scope for some novel query evaluation and optimization algorithms. If you know any good resources or books dealing with this specific area, then please tell me!

Bill the Lizard's user avatar

asked Jan 9, 2010 at 1:18

user245120's user avatar

2

First you need to learn about relational calculus and make a compiler to deal with making it from sql, thankfully sql is an easy language and this is not bad.

Then get familiar with bx-trees for your indexes. Then make a commit and rollback space and that is pretty much all there is to it. It’s not rocket science, compared to other projects you might undertake, but it’s definitely something you better start right away if you want a good result by the end of the semester/year.

edit: Oh, and as for modern architecture goes, trees don’t usually benefit much from multithreading. Neither do disk reads. On the other hand, it’s crucial for high performance to use the whole of your memory using OS level calls, not just the memory normally addressable in a process.

answered Jan 9, 2010 at 10:37

Charles Eli Cheese's user avatar

As your looking to take advantage of modern CPU architectures, it might be worth looking at the MonetDB project. The project has produced a lot of research around optimising databases for modern CPU architecture, using column stores and storing compressed pages in memory — only decompressing them in the CPU cache to get significant speeds for very large databases.

This approach (column oriented storage + compression) and a more traditional query engine, perhaps based on the SQLite engine, should be a good basis for a project.

answered Jan 9, 2010 at 17:42

Robert Christie's user avatar

Robert ChristieRobert Christie

19.9k8 gold badges42 silver badges37 bronze badges

1

Since your professor mentioned metaprogramming, you might want to look at the following:

  1. WAM — Warren Abstract Machine. This compiles prolog code into a set of instructions that can be executed on an abstract machine. The idea is similar to jvm and cli. You don’t need to go into this in detail, just understand the idea of an abstract machine.

  2. JVM, CLI — same as above.

  3. Tools such as lex, yacc, flex, bison. Since you will be writing essentially an interpreter/compiler for SQL commands, you probably want to use some tools. This can be viewed as a form of metaprogramming, since you are using a language to write a tool — so you are programming at the meta-level.

  4. Again, the idea of meta-programming — perhaps you can augment your language with constructs that will allow your SQL compiler/interpreter to automatically optimize for parallel queries. These can be implemented as hints etc. to the compiler.

  5. Recompilers — you might want to write an interpreter/compiler that recompiles the initial queries into ones that can run in parallel for your target architecture. For example, for an N-core architecture, it might recompile a query into N-subqueries that execute in parallel, then combine the results.

I’m not sure that you should go into a great deal of research into standard optimization practices. These can be complex, and the subject of a lifetime of research in themselves. Since the object of the exercise is to take advantage of parallel processing, and meta-programming, that should be the focus of your research.

answered Jan 9, 2010 at 17:53

Larry Watanabe's user avatar

Larry WatanabeLarry Watanabe

10.1k9 gold badges42 silver badges45 bronze badges

1

Except for proprietary issues, how about optimizing MySQL in such ways? This is no trivial task though. Query optimization which takes advantage of parallel processing might be an entire term’s work.

It’s better to stand on the shoulders of giants to reach upward than to stand beside them.

answered Jan 9, 2010 at 1:23

wallyk's user avatar

wallykwallyk

56.4k16 gold badges85 silver badges147 bronze badges

5

База данных с соединением клиент-сервер

Данный проект демонстрирует работу трех модулей: база данных (Modules/DB), парсер (Modules/Parse) и сервер (Modules/Server).

Установка

Для работы программы требуются следующие библиотеки: boost (boost::asio), bison и flex. Для сборки используется cmake и make. Используется стандарт c++11. Если вы используете дистрибутив ubuntu или debian, то установка весьма проста:

sudo apt-get install flex bison cmake libboost-all-dev

Далее программу нужно собрать. Перейдите в директорию с проектом и выполните:

mkdir build && cd build
cmake ..
make

Модули

База данных

В качестве примера я использую базу данных студентов. Для хранения используется формат CSV, данные загружаются в память и хранятся в объекте std::set, который представляет из себя самобалансирующееся дерево. У объекта базы данных прописаны основные запросы для работы с ней. Они реализуют обертку над методами объекта std::set. Для хранения данных используется объект Student, который хранит поля first_name (Имя), last_name (Фамилия), group (Группа) и course (Курс), settled (Поселен ли студент), city (Город).
Для генерации примера базы данных написан генератор. Для запуска используйте команду:

или

./generator students.csv 1000

Число задает количество записей.

Парсер

Парсер выполнен с использованием программ flex и bison и способен распозновать корректные для него скрипты.
Скрипт состоит из команд, разделенных точками с запятой. Каждая команда начинается с операции (select, insert, delete), далее идут параметры (first_name, last_name, group, settled, city) со своими значениями указанными через =. То есть для того, чтобы получить всех студентов из группы 210, нужно написать:

Пробельные символы игнорируются. Для того, чтобы вывести всех, вместо параметров указывается ключевое слово all:

Insert требует всех параметров, в связи с чем insert all; работать не будет. Delete работает аналогично select.

delete all;
delete group=210 first_name = Изя;

Для того, чтобы запустить парсер, используйте команду:

./parser students.csv test_simple.dbq

Где test_simple.dbq представляет из себя простой скрипт:

Сервер

Сервер реализован с применением boost::asio. Сервер является асинхронным и способен поддерживать несколько подключений. Для остановки сервера просто напишите stop в консоли. Сервер для каждого подключения создает свой интерпретатор, загружает туда запрос и возвращает клиенту ответ.
Клиент подключается к серверу и отправляет запрос (Запрос отправляется только тогда, когда ввод закончен. В консоли это Ctrl+D, для файла это EOF). Как только запрос отправлен, программа ловит ответ и завершает работу.
Для того, чтобы протестировать сервер и клиент, запустите сначала сервер:

./server students.csv 4444

А потом клиент:

В клиент можно сразу передать файл скрипта:

./client 127.0.0.1 4444 < test_simple.dbq

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

Алгоритм создания СУБД

1. Анализ входных данных.

2. Составить план из задач, для которых создаётся БД.

3. Определиться с форматом внутренних и выходящих документов.

4. Создание таблиц и связей с ними.

5. Тестирование ввода данных.

6. Создание формы для ввода данных в БД.

7. Создание отчётов.

8. Создание запросов для анализа данных.

9. Сопровождение БД, т. е. корректировка работы БД в процессе.

10. Управление доступом к БД.

Основным элементом структуры БД являются поля. Поля представляют собой столбцы таблицы, описывающие какое-то одно свойство. Записи — это строки таблицы.

Скриншот 06-10-2021 235941.jpg

Рис. (1). Структура БД

  • Размер поля (выражается в знаках (или символах)).
  • Имя поля (должно быть уникальным, чтобы не происходило путаницы).
  • Подпись (отображается в заголовке столбца).
  • Тип поля (устанавливает формат данных).

Скриншот07102021010704.jpg

Рис. (2). Свойства полей БД

Ключевое поле — это поле, значения которого однозначно определяют каждую запись в таблице.

Обрати внимание!

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

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

Источники:

Рис. 1. Структура БД. © ЯКласс.

Рис. 2. Свойства полей БД. © ЯКласс.

Понравилась статья? Поделить с друзьями:
  • Как написать свою ссылку на ватсап
  • Как написать свою социальную сеть
  • Как написать свою соц сеть
  • Как написать свою собственную песню
  • Как написать свою собственную книгу