CMS на SQL. Как сделать веб-оболочку для базы данных SQL Server в виде личных кабинетов на сайте — Руслан Раянов на vc.ru

В этой статье рассмотрим вопрос создания веб-оболочки для базы данных SQL Server на примере нашей платформы Falcon Space и посмотрим основные отличия от классической разработки системы по полному стеку технологий.

782 просмотров

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

Разработка учетной системы на полном стеке (fullstack)

Самописные системы разрабатываются на базе полного стека разработки с N слоями:

  • проектируется база данных
  • создается слой доступа к данным
  • создается слой бизнес-логики
  • разрабатывается API или слой контроллеров
  • делается верстка
  • к ней подключается динамика за счет front end программирования.

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

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

Fullstack разработка — это долго, дорого и много ошибок

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

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

Полное управление через SQL — новая парадигма

Это привело нас к идее, а почему бы и другие все модули не попробовать сделать по подобному принципу — формы, таблицы, графики, дашборды и прочее.

Что дает в итоге такой подход:

  • можно менять бизнес-логику на лету (просто поменяв хранимую процедуру). В случае обычного N-слойного приложения необходима перекомпиляция и обновление программы.
  • скорость внесения изменений. Очень важно иметь возможность быстро вносить изменения, а не ждать разработчиков по 2 недели, когда они внедрят изменения в систему.
  • основная сложность ложится на один слой и локация ошибки с высокой степенью вероятности находится только в одном слое — SQL процедурах. Это упрощает поиск ошибок и минимизирует количество сбоев на front end.

Как это выглядит изнутри

Возьмем к примеру вывод таблицы.

На входе — это сниппет.

<div data-code=»table1″ data-itemid=»1″></div>

Ваш JS движок обрабатывает подобные компоненты и запрашивает у базы описание по компонентам и данные для них (все через знанимые процедуры).

Полученные данные JS движок выводит в виде таблицы.

Данные удовлетворяют неким правилам/стандартам. Например, для таблиц у нас правила примерно выглядят так:

процедура GetItems выдает в SELECT 1 данные таблицы, в SELECT 2 — данные о пагинации, в SELECT 3 — настройки вывода таблицы.

К примеру, если в SELECT 3 передать select 1 Compact — то таблица будет выведена в компактном режиме.

Редактирование SQL для таблицы вывода страниц

Так выглядит таблица в компактном режиме

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

Процедуры делятся на системные (обслуживают компоненты и внутренние потребности системы) и пользовательские (задают вывод данных).
Редактирование процедур происходит через интерфейс панели управления, т.е. нет необходимости искать каждый раз хранимую процедуру в SQL Server Management Studio.

Идея Falcon Space — Сниппеты в разметке+ управление бизнес-логикой через SQL + гибкие компоненты ядра

Плюсы и минусы подхода с полным управлением через SQL

Какие дополнительные плюсы дает подобный подход?

1. Быстродействие. Вы работаете с чистым SQL без лишних прослоек в виде ORM. Это дает хорошее быстродействие, и оно ограничивается, по сути, быстродействием вашего написанного SQL запроса.

2. Созданный функционал — это только SQL и данные в таблицах (что также можно представить в виде SQL скрипта). Вы можете легко переносить между разными системами SQL для отдельных компонентов. Это возможность быстро наращивать кодовую базу и адаптировать ее в других подобных приложениях.

3. Не нужна компиляция. Поменяли процедуру — получили сразу в системе другой результат. По сути разработка идет в realtime, параллельно с использованием.

4. Локализация ошибок — большинство ошибок лежат в вашем SQL, а не разбросаны по всему стеку. Есть проблема? Проверяем работы процедуры в SQL Management Studio и анализируем вход и выход.

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

6. Уменьшение требуемых компетенций для поддержки системы. В нашем случае мы сводим все к двум компетенциям — знание SQL для бизнес-логики и Bootstrap для стилизации и вывода данных.

7. Уменьшение количества велосипедов. Программисты не могут больше делать в системе три вида по-разному сделанных таблиц. Все унифицируется и разработка идет быстрее.

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

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

Возможности платформы Falcon Space

Более подробное описание как изнутри работает система можно найти в вводной статье документации Falcon Space.

В статье На пути к созданию продукта. История создания Falcon Space можно более глубоко погрузиться в предпосылки создания системы и ее особенности.

P.S. Мы реализовали несколько типовых решений на базе нашей платформы. Вы можете посмотреть их демо здесь — demo.web-automation.ru

Источник:

Облачная система управления контентом базы данных / Хабр

«Я беру камень и отсекаю всё лишнее»
Микеланджело Буонарроти

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

В общих чертах, основную идею можно понять из заголовка. Я хочу построить облачную систему управления контентом баз данных (CDBCMS — Cloud database content management system). Проще говоря, это веб-сервис для обеспечения доступа к базе данных, генерирующий красивую и удобную панель для редактирования содержимого вашей базы данных.

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

Итак, для чего я написал эту статью:

1. Поиск уже существующих решений (я честно пытался найти что-то подобное — буду благодарен, если приведете в комментариях ссылку).
2. Изучение спроса среди IT-сообщества.
3. Поиск желающих присоединиться к разработке.

Шо вам с меня надо?

Все знают, что такое CMS — Content management system. Говоря «CMS», мы, как правило, подразумеваем Web Content Management System и совсем забываем суть этого определения. Мы говорим о системах построения веб-сайтов, вместо систем управления содержимым.

По моему личному опыту, основное предназначение CMS состоит в том, чтобы предоставить простому редактору возможность добавления новостей на сайт. Да, там всегда можно добавить новые статичные страницы, да, можно установить навороченные виджеты, да, можно менять CSS в красивом редакторе. Но, это делаете Вы, а не заказчик и не редактор. Вы делаете это один раз прежде чем сдать заказчику веб-сайт визитку/каталог/интернет-магазин.

И хорошо, если CMS позволяет спрятать от редактора все лишнее, чтобы он не выстрелил себе в ногу. Обычно, вам гораздо удобнее было бы реализовать тот же функционал при помощи базовых средств вашего любимого языка/фреймворка. И помимо всего прочего, чем сложнее и «универсальнее» CMS, тем больше граблей и костылей кроется внутри. И тем выше вероятность столкнуться с ними при малейшем отклонении от заданного разработчиками CMS направления.

И шо вы таки предлагаете?

Я надеюсь, вы уже поняли, к чему я вас склоняю. Если вся соль в админке, то почему бы не строить веб-сайты так, как Вам нравится, а вместо построения админки для заказчика/редактора, просто воспользоваться некой системой управления содержимым? Пусть такая система не лезет в тонкости реализации нашего веб-сайта, а просто даст возможность красиво и удобно добавлять новости на сайт. Давайте возьмем типичную CMS, отсечем все лишнее и оставим только панель управления контентом. А впрочем, давайте пойдем дальше и обзовем это облачным сервисом, который соединится с нашей БД и сам нарисует админку, не требуя с нашей стороны каких-то дополнительных серверных мощностей и установок стороннего софта. Просто разрешим одному IP-адресу обращаться по одному паролю только к определенному набору таблиц, доступных для редактирования.

А мане нужен етот гембель?

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

Веб-сайт

Предположим вам нужно создать веб-сайт. Конечно ваш заказчик хочет самостоятельно добавлять на сайт новости/товар/фотографии (нужное подчеркнуть). В таком случае, у вас есть две опции:
а) использовать CMS
б) самостоятельно сделать админку

Конечно, если ваша контора или лично вы являетесь спецом в области конкретной CMS и заказчика это устраивает, то такого вопроса не стоит и вы просто делает все как обычно(разворачиваете новый экземпляр CMS и создает сайт. Все идет отлично, до тех пор, пока заказчик не захотел некоторый «Функционал». Этот «Функционал» никак не вписывается в существующую архитектуру CMS, вам приходится всячески изворачиваться и продираться через дебри таблиц с говорящими названиями «CONTENT_127» и «TABLE_45». Кроме того, есть CMS-ки c унылыми и/или непонятными простому смертному редактору админками.

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

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

Мобильное приложение

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

База данных

Предположим у вас есть корпоративная база данных за семью замками. Скорее всего у вас даже есть Delphi приложение, написанное для добавления новых объектов в систему главбухом. Приложение уже давно морально устарело, а вам нужно ввести новую сущность в систему. Вы устанавливаете Borland Delphi 7 на виртуальную машину с Windows XP, открываете исходники и… Form1, Button1, Button1_OnClick7, вся логика сосредоточена в обработчиках кнопок. Переписывать все с нуля? Пытаться прикрутить в этот интерфейс новую таблицу?

Я шо-то не понял

А теперь представьте, что вы открываете волшебный веб-сайт, регистрируетесь, сообщаете ему строку подключения к вашей БД (да, придется разрешить доступ к БД с одного IP-адреса). Тут же видите все свои таблицы. Выбираете нужные редактору таблички. Обзываете их как душе угодно (Table_75 — это на самом деле новости). Указываете доступные для просмотра/редактирования столбцы и их названия для отображения редактору… И получаете готовую админку. Админка уже умеет отображать таблицу с пейджером, сортировкой и фильтрацией, умеет редактировать записи. Выборка идет постраничная, не тянутся все данные целиком. Можно ограничить доступ для разных типов пользователей, вплоть до различных столбцов. Если вы используете CMS — просто укажите, какие CMS таблицы в БД хранят нужные для редактирования данные, сервис отобразит более удобную админку, чем то, что шло из коробки. Если вы строили веб-сайт с нуля, то вам не нужно писать однотипные страницы с пейджером. Если вы создаете мобильное приложение, то вам не нужно вникать в тонкости построения веб-приложений, просто пишите приложение, а админку сделает чудо сервис. Все тоже самое с корпоративным решением, но для обеспечения еще большей безопасности, у меня есть отдельные мысли, о которых я, возможно, расскажу позже.

И шо вы себе думаете?

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

P.S.: Основано на реальных событиях.
P.P.S.: Все совпадения с реальными проектами и таблицами случайны.

CMS и база данных: понимание разницы

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

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

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

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

1. Обзор

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

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

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

При этом, что означает каждое понятие? какая между ними связь? и как они могут работать независимо? Это часть того, к чему мы собираемся подойти в этой статье.

2. Что такое CMS?

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

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

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

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

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

3. Что такое база данных?

База данных обычно относится к множеству наборов данных, организованных в электронном виде и индексированных в структурированном формате.

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

Реляционные базы данных — это наиболее распространенный тип баз данных со структурой связанных таблиц. Столбцы таблицы представляют атрибуты данных, а строки — значения данных.

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

4. Различия между CMS и базами данных

В следующей таблице мы выделяем основные различия между системами управления контентом и базами данных:

90 048
CMS БАЗА ДАННЫХ
Назначение Управление контентом Управление данными
Форматы контента Высокий уровень: статьи, страницы, сообщения, Документы, медиафайлы, продукты, книги, … Низкий уровень: числовые значения, тексты, даты и время, правда/ложь, …
Компоненты Управление контентом, контроль доступа пользователей, инструменты редактирования, рабочий процесс, хранилище, … Транзакции, индексирование, доступ к данным, обработчик запросов, язык доступа, …
Пользователи/исполнители Не разработчики Разработчики и администраторы БД
Язык программирования PHP, Python, C#, … (у каждой CMS свои языки программирования) Язык структурированных запросов (SQL)
Примеры 9 0107 WordPress, Joomla, MS SharePoint MySQL, SQL Server, Oracle
CMS и база данных

5.

Связь между CMS и базами данных

довольно сложная и сложная задача.

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

Учитывая это, какова связь между системами управления контентом и базами данных?

Форматы контента

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

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

CMS и базы данных управляют контентом разного уровня абстракции!

Зависимость

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

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

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

CMS использует базу данных для хранения «низкоуровневых» форм своего «высокоуровневого» контента!

Независимость

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

Например, CMS без базы данных — это особый тип CMS, который работает независимо без специальной системы баз данных.

С другой стороны, все ядра баз данных поддерживают хранение данных для ЛЮБОГО приложения, а не только для программного обеспечения для управления контентом.

CMS и базы данных тесно связаны, но совершенно независимы!

6. Какая база данных обычно используется в CMS?

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

Вот список наиболее часто используемых баз данных на платформах CMS:

MySQL MySQL — очень распространенная система управления реляционными базами данных. Раньше он был бесплатным, с открытым исходным кодом и работал как с небольшими, так и с большими приложениями.
SQL Server SQL Server — это система управления реляционными базами данных, разработанная Microsoft. Он обслуживает различные рабочие нагрузки от небольших до крупных приложений.
PostgreSQL PostgreSQL — это бесплатная система управления реляционными базами данных с открытым исходным кодом. Это расширенная база данных корпоративного класса, которая поддерживает как реляционные, так и нереляционные запросы.
Оракул База данных Oracle — это передовая многомодельная система управления базами данных, разработанная корпорацией Oracle. Он обычно используется для онлайн-обработки транзакций и хранения данных.
MariaDB MariaDB — это форк системы управления базами данных MySQL, разработанный сообществом. Предполагается, что он останется бесплатным и с открытым исходным кодом в соответствии с Стандартной общественной лицензией GNU.
SQLite SQLite — это механизм базы данных, представляющий собой библиотеку, которую разработчики программного обеспечения могут встраивать в свои приложения.
MongoDB MongoDB — это кроссплатформенная программа базы данных, ориентированная на работу с документами. Таким образом, она классифицируется как база данных NoSQL.
Часто используемые базы данных в системах управления контентом

7. Заключение

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

Подводя итог:

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

База данных CMS — Business Intelligence (BusinessObjects)

Перейти к концу баннера

Перейти к началу баннера

Перейти к концу метаданных

  • Создано Джошуа Куном 17 мая 2013 г.

Перейти к началу метаданных

Главная

Свернуть все

Развернуть все Свернуть все

    • Выкройка дома
    • Документация
    • Учебники
    • Оценщик размера BI4
    • Матрица доступности продуктов
    • Место идей

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

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

    Для этого шаблона Windows используется клиент и сервер базы данных SQL Server 2008 Release 2. Аккаунт пользователя базы данных и схема были созданы специально для этого шаблона для использования в базе данных CMS. Учетной записи пользователя базы данных потребуются разрешения на чтение, запись и изменение таблицы. И ему потребуются разрешения для создания хранимых процедур в схеме. В этом шаблоне рассматривается конфигурация SQL Server 2008 Release 2, описанная в разделе Установка промежуточного программного обеспечения SQL Server.

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

    Дополнительные сведения о базе данных CMS и других серверах платформы BI см. в Руководстве администратора BIP 4.0 SP5.


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

    Этап развертывания

    Имя пользователя/схемы CMS

    Имя пользователя/схемы аудита

    Доказательство концепции (POC)

    BI4CMSPOC

    BI4AUDPOC

    Развитие

    BI4CMSDEV

    БИ4АУДДЕВ

    Обеспечение качества

    BI4CMSQA

    BI4AUDQA

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

    БИ4КМСПРОД

    БИ4АУДПРОД

    Сведения о базе данных SQL Server, используемой для базы данных CMS в этом шаблоне

    Обзор базы данных CMS для этого шаблона Windows

    Версия

    SQL Server 2008 R2

    Имя базы данных

    смс08р2у03

    Имя сервера

    VANPGDBSQL03.

    No related posts.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *