База данных для блога


Оглавление (нажмите, чтобы открыть):

Проектирование БД для блога

Я новичек в программировании (за плечами собственно только знание основ программирования,
изученные на примере языка «С»), хочу уйти в web, и сейчас самостоятельно изучаю PHP.
Как известно обучаться лучше всего на практике поэтому решил делать блог.
В данный момент моя проблема в том что я не знаю принципов проектирования БД вообще и
для веб приложений в частности.

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

08.02.2011, 14:28

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

Создание админ панели (не для блога)
Собственно выучил html и css. Для себя начал делать проект, вроде как всё оформил, но не хватает.

Генерация страниц для каждого поста блога
Есть база данных с такими полями id (уникальный номер статьи), title (заголовок статьи), date (дата.

Делаю по урокам простую CMS для блога, но выводит ошибку
Такая проблема делал по урокам cms, до этого учил основы и разбирался. Хотел начать с простенького.

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

Структура БД для блогов

beejuice

Новичок

Структура БД для блогов

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

Нужно писать блог, который будет хорошо работать на средней нагрузке (от 100 до 1000 запросов в минуту). Может кто сталкивался с подобной задачей и может посоветовать как лучше организовать БД.

Работа ведется на PHP+MySQL

Alexandre

PHPПенсионер

а объем базы какой предполагается?

beejuice

Новичок

> а объем базы какой предполагается?

Растущий. Как я могу на старте точно прогнозировать размер БД. Думаю что через какое-то время размер будет исчисляться гигабайтами.

Движок должен надежно работать с БД очень большого размера.

Апокалипсис

тех дир matras.ru

beejuice

Новичок

> это ерунда. у меня в чате при 30 челах бывает до 5 тыс запросов в минуту. + он висит пока ещё на виртуальном хосте. (переезжаю щас на VPS)

У вас в чате я думаю таблица с сообщениями строк на 100? А теперь представте как себя будет вести ваш чат, если будет 1 000 000 записей при том же кол-ве обращений?

Апокалипсис

тех дир matras.ru

Alexandre

PHPПенсионер

имеется ввиду те таблицы, по которым будет осуществлен скан.
если мы ожидаем 1000 запросов в секунду, пусть читающих,
пусть в среднем стр. генерит 5-10 запросов, то в среднем должно сидеть на сайте одновременно человек 200. Пусть из них пишут только 5ть.
это прогнозируемый размер увеличения БД:
постов в секунду — пусть — 1
в минуту — 60
час 3600
база-то будет о-го-го.

блин. осмотрелся, подумал в секунду — а там 1000 в минуту,
это действительно не так много.

simpex

Новичок

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

полем enum со значениями a,b,c,d
или int(1) и соответствующими числами 0, 1,2,3, . 9

Новичок

> Посоветуйте, пожалуйста, что-нибудь почитать про разработку . который будет хорошо работать на средней нагрузке

performance coding soup to nuts pdf

Alexandre

PHPПенсионер

см. структуру таблиц phpBB или LJ
исходники открыты ( LJ — перл, но для структуры БД это по барабану )

Базы данных для web-сайтов

Р. Киплинг, «Слоненок»

С чего обычно начинает человек, делающий свои первые сайты? Сперва он осваивает HTML — благо это язык гипертекстовой разметки, а не язык программирования. Затем он узнает о возможности отделить оформление страницы от ее содержания с помощью таблиц каскадных стилей (CSS). Наконец следом многие осваивают JavaScript, язык программирования скриптов на стороне клиента.

На заметку: скрипты делятся на два вида. Одни выполняются на стороне клиента — то есть без изменений скачиваются на компьютер пользователя, где их выполняет сам браузер. Другие выполняются на стороне сервера. Пользователь не может получить их исходный код, а видит только результат работы — будь то текст, картинка или HTML-страничка. Первые (например, JavaScript) созданы затем, чтобы слегка разнообразить отображение страниц, вторые (например, PHP или JSP) на лету создают динамические страницы: каталоги, форумы, поисковики. Именно они и позволяют делать все то, о чем мы поговорим в этой статье.

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

К примеру, если вы хотите сделать сайт с новостной лентой, легко обновляемой галереей или гостевой книгой, то без программирования на стороне сервера уже не обойтись. Вы придете к необходимости создания того, что сейчас называется «движком» сайта, или, если выражаться более солидно, системой управления содержимым (калька с английского Content Management System (CMS).

Для большей наглядности зайдем с другой стороны и на примере посмотрим, чем отличается статический сайт от динамического. Представьте себе продуктовый ларек и продуктовый магазин. У ларька все на одном месте — и доставка, и склад, и продажа. Все это обычно вручную обслуживается одним человеком. И все на виду. Другое дело — магазин. Есть торговый зал, где продавцы общаются с покупателями. А есть служебные помещения, где совершенно другие люди занимаются оформлением и обеспечением торговли. А есть еще и складские помещения. Чувствуете разницу?

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


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

Мне доводилось встречать выложенные в интернете бесплатные «движки», авторы которых заявляли в числе достоинств тот факт, что их движок обходится без MySQL. На практике это всегда означало, что авторы в качестве базы данных использовали текстовый файл, где данные разделяются запятыми. Это хорошо тем, что от хостинга не требуется поддержки баз данных. Ну допустим. А чем это плохо? Пока база данных мала, никаких особых проблем не возникнет. Но если она состоит из десятков тысяч записей о товарах, да еще и хранит разного рода связанную с ними информацию (о заказах, например), то разницу вы почувствуете очень быстро.

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

Из них наиболее популярны в интернете MySQL и PostgresSQL. Кстати, первая начинала свой путь с довольно простой и бесхитростной SQL-системы, но с каждой версией она все больше наращивала возможности, и место предельно упрощенной SQL-системы постепенно заняла SQLite.

Реляционные базы данных

В. Левшин, Э. Александрова,
«Путешествие по Карликании и Аль-Джебре»

Само понятие реляционный (англ. relation — отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd), сотрудника фирмы IBM. В 1970 году им был создан формальный аппарат реляционной алгебры для обработки данных. Позже он сформулировал 12 правил, которым должна соответствовать любая система по управлению реляционными базами данных (RDBMS — Relation Database Management System).

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

Особенности реляционных баз

Основные особенности реляционных баз можно сформулировать так:

  • Все данные представлены в виде набора простых таблиц (двумерных массивов), разбитых на строки и столбцы, на пересечении которых расположены данные.
  • У каждого столбца есть имя, уникальное в пределах таблицы, причем все значения в одном столбце — однородны, т.е. имеют один тип.
  • Каждая строка имеет одно или несколько полей, набор значений в которых уникален в пределах таблицы. Этот набор называется первичным ключом (primary key) и служит для идентификации строки. Этот принцип не допускает, в частности, хранение в таблице совершенно одинаковых строк.
  • Имя таблицы, имя столбца и первичный ключ однозначно определяют хранимый элемент данных.
  • Строки в реляционной базе данных не упорядочены. Упорядочивание производится в момент формирования ответа на запрос.
  • Запросы к базе данных возвращают результат в виде таблиц, которые также могут выступать как объект для новых запросов.

Чтобы такое изложение не воспринималось скучным и сложным, приведу поясняющий пример. Вот простая таблица — справочник стран. Назовем ее COUNTRIES.

Справочник стран COUNTRIES
ID NAME
1 Россия
2 Франция
3 Марокко
4 Япония

В таблице COUNTRIES всего два столбца:

  • ID — код страны;
  • NAME — ее название.

Столбец ID служит первичным ключом таблицы, а столбец NAME содержит ту полезную информацию, которую мы и будем стремиться извлекать запросами. Все данные столбца ID — целочисленны, столбца NAME — содержат текстовую информацию.

Отношения между таблицами

Чтобы база данных стала реляционной, одних данных мало. Между ними нужны еще и связи (те самые relations, от которых и пошло слово «реляционный»).

Для связи между таблицами служит так называемый внешний ключ (foreign key). Название довольно точно выражает его суть. Если в таблице A есть столбец для хранения первичного ключа таблицы B, то такой столбец и называется внешним ключом. Первичные и внешние ключи устанавливают связи между таблицами, превращая набор таблиц в цельную конструкцию — реляционную базу данных.

Приведу пример. Допустим, мы создали еще одну простую таблицу — справочник товаров. Назовем ее GOODS.

Товарный справочник GOODS
ID NAME PRICE UNIT COUNTRY
1 Яблоки 50.00 кг Россия
2 Груши 60.40 кг Франция
3 Апельсины 40.00 кг Марокко
4 Макароны 21.00 шт Франция
5 Кефир 25.30 шт Россия
6 Молоко 30.50 шт Россия

Ее колонки: ID — первичный ключ, NAME — название товара, PRICE — его цена, UNIT — краткое название единицы измерения, COUNTRY — название страны-производителя.

Хорошо ли построена такая таблица? Вроде бы всем упоминавшимся выше принципам она удовлетворяет: уникальные имена столбцов с однородными данными, строки с уникальным первичным ключом. Казалось бы, все на месте. Тем не менее построена она непрофессионально. Здесь мы подходим к принципам, о которых я еще не упоминал, — к понятию о нормализации таблиц. Суть в том, чтобы всюду, где только можно, избегать избыточности в хранении данных путем выделения их в отдельные таблицы.

Посмотрим на нашу таблицу GOODS. Чем она плоха? Представьте себе, что завтра придется изменить название какой-нибудь страны. Такое случается часто. Бирма когда-то меняла свое название на Мьянму, Польша — на Польскую Республику. Хочется ли вам менять огромное количество строк во всех таблицах, где эти страны упоминаются? Представьте также, что вас попросят отобрать запросом весь штучный товар. Можете ли вы быть уверены в том, что оператор всюду набил эту аббревиатуру правильно и одинаково? Скорее всего, окажется, что в таблице встречаются все мыслимые вариации: «шт», «Шт», «шт.», «штук» и «штуки».

Думаю, проблема понятна. Выходом из этой ситуации будет выделение из нее двух других таблиц: справочника стран (COUNTRIES) и справочника единиц измерений (UNITS).

Справочник единиц измерения UNITS
ID NAME SHORT_NAME
1 Штуки шт
2 Килограммы кг

Сам справочник товаров GOODS будет теперь выглядеть совершенно по-другому (см. таблицу).

Товарный справочник GOODS после нормализации
ID NAME PRICE UNIT_ID COUNTRY_ID
1 Яблоки 50.00 2 1
2 Груши 60.40 2 2
3 Апельсины 40.00 2 3
4 Макароны 21.00 1 2
5 Кефир 25.30 1 1
6 Молоко 30.50 1 1

Что изменилось? Вместо столбцов с названиями единиц измерения и стран появились столбцы UNIT_ >

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

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

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

Язык запросов. Мини-учебник по SQL

Аладдин и волшебная лампа

Что такое SQL?

SQL — это самый распространенный язык запросов к базам данных. Расшифровывается аббревиатура так: Structured Query Language — «язык структурированных запросов».

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

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

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

Строим запросы

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

Временно оставив в стороне формирование структуры таблиц, поговорим об операциях с данными. Начнем с запросов. В основе запроса лежит команда SELECT. Ее задача — взять исходные данные таблиц и на основании запроса пользователя построить временную «отчетную» таблицу, которую и вернуть в виде результата. Очевидно, что запросы ничего не меняют в базе данных. Их задача — извлекать данные в указанном виде. Итак, приступим:

Этот запрос извлечет все данные из таблицы GOODS, сортированные по названиям товаров. Все — потому что после ключевого слова SELECT стоит «звездочка»: она дословно означает «все колонки».

Порядок сортировки (в нашем случае — «name»), вообще говоря, может состоять из нескольких полей, перечисленных через запятую. В этом случае сначала выборка сортируется по первой указанной колонке, а те значения, которые оказались в ней одинаковыми, дополнительно сортируются по второй, и так далее.

Ограничиваем набор столбцов

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

Результат выборки
NAME PRICE
Яблоки 50.00
Груши 60.40
Апельсины 40.00
Макароны 21.00
Кефир 25.30
Молоко 30.50

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

Этот запрос извлечет названия и цены товаров для всех записей, где цена меньше 30, и отсортирует их в порядке убывания цен. Ключевое слово WHERE служит для ограничения выборки по строкам, а ключевое слово DESC (descending) указывает сортировать не по возрастанию (как обычно), а по убыванию. Результат опять же можно посмотреть в виде таблицы.

Результат выборки
NAME PRICE
Кефир 25.30
Макароны 21.00

Связываем таблицы

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


SELECT goods.id, goods.name, goods.price,
units.name AS unit, countries.name AS country
FROM units, countries, goods
WHERE units. > ORDER BY goods.id

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

Из таблиц UNITS и COUNTRIES отобраны строки, первичные ключи которых равны значениям внешних ключей UNIT_ID и COUNTRY_ID. Чтобы уточнить, из какой таблицы мы хотим взять поля ID и NAME (ведь такие названия есть в нескольких таблицах), мы через точку приписываем имя таблицы к их названиям.

Для удобства можно временно назначить таблицам более короткие псевдонимы — это делается в секции FROM, через пробел сразу после названий таблиц. Назначим для UNITS, COUNTRIES и GOODS в качестве псевдонимов буквы U, C и G, соответственно:

SELECT g.id, g.name, g.price, u.name AS unit, c.name AS country
FROM units u, countries c, goods g
WHERE u. > ORDER BY g.id

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

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

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

SELECT g.id, g.name, g.price, u.name AS unit, c.name AS country
FROM goods g
LEFT JOIN units u ON u. > LEFT OUTER JOIN countries c ON c. > ORDER BY g.id

В этом запросе явно обозначена главная таблица — GOODS. Также здесь обеспечено «левое присоединение» вспомогательных таблиц через внешние ключи к основной таблице (LEFT JOIN) и внешнее (OUTER) присоединение таблицы стран.

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

Мастер Йода рекомендует:  PHP для профессионалов

Считаем строки

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

Он использует функцию COUNT и возвращает число строк в таблице GOODS. При этом результату, который возвращает функция, присваивается псевдоним CNT. Вот как это выглядит:

Результат выборки
CNT
6

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

SELECT MAX(price) AS max_price, MIN(price) AS min_price
FROM goods WHERE unit_ >

Такой запрос вернет нам максимальную и минимальную цены, встречающиеся у весовых товаров (напомню, что первичный ключ 2 для весовых товаров в нашей базе данных соответствует килограммам). Результат будет выглядеть как таблица из одной строки и двух столбцов. Называются столбцы, как мы и указали: MAX_PRICE и MIN_PRICE, а в двух ячейках размещаются вычисленные значения.

Более сложные агрегирующие запросы

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

SELECT country_id, MAX(price) AS max_price, MIN(price) AS min_price
FROM goods GROUP BY country_id

Для указания столбцов, по которым производится группировка, служит блок, начинающийся с GROUP BY. Выборка показана в таблице.

Результат выборки
COUNTRY_ID MAX_PRICE MIN_PRICE
1 50.00 25.30
2 60.40 21.00
3 40.00 40.00

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

SELECT c.name AS country, a.max_price, a.min_price
FROM countries c,
(SELECT country_id, MAX(price) AS max_price, MIN(price) AS min_price
FROM goods GROUP BY country_id) a
WHERE c. >

Наш предыдущий запрос включен сюда в скобках как самая обычная таблица с псевдонимом А (вот и еще одна полезная функция псевдонимов).

Результат выборки
COUNTRY MAX_PRICE MIN_PRICE
Россия 50.00 25.30
Франция 60.40 21.00
Марокко 40.00 40.00

Как вносить изменения в таблицы?

Если продолжить сравнивать базу данных с магазином, команда SELECT отражает лишь содержимое его прилавков, но не отражает сам процесс торговли. Товар на прилавках должен пополняться при поставках, исчезать в ходе продаж, менять цену и т.п. Значит, в SQL должны быть средства для обеспечения этих манипуляций. И такие средства, конечно, есть.

Управление данными в SQL осуществляется тремя основными командами: INSERT — для добавления новых строк, UPDATE — для их редактирования, DELETE — для удаления.

Добавим в таблицу COUNTRIES новую страну:

INSERT INTO countries (id,name) VALUES (4,»Бирма»)

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

После этого мы узнаем, что страна эта давно уже сменила название на Мьянму и спешно исправляем оплошность:

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

Хочу обратить внимание, что блок WHERE в командах UPDATE и DELETE может воздействовать не только на одну строку, но и на любую их совокупность, заданную условием, а его отсутствие оказывает действие на всю таблицу. Для того чтобы удалить из таблицы GOODS все весовые товары, мы можем выполнить команду:

DELETE FROM goods WHERE unit_ >

А для того чтобы очистить всю эту таблицу — команду:

В системе MySQL существует еще особая команда REPLACE, замещающая строки. Работает она как силовой вариант команды INSERT (то есть если строка с требуемым первичным ключом уже существует, команда не ругнется, а удалит двойника и все равно вставит затребованную строку).

Создаем базу данных

Управление базами данных как объектами

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

MySQL — продукт шведской компании MySQL AB. Ее основатели — Дэвид Аксмарк, Аллан Ларсон и Майкл Видениус (последний больше известен по прозвищу — Монти). По одной из версий, первая часть названия продукта (My) — не что иное, как англизированная запись имени дочери М. Видениуса. Однако точно за происхождение названия сегодня не могут поручиться даже отцы-создатели. Существует версия, по которой «my» — это префикс, с которого начинались названия рабочих каталогов на их компьютерах.

Из всех команд чаще всего нам будут нужны три: CREATE (создать), ALTER (изменить) и DROP (уничтожить).

Чтобы создать новую базу данных с названием, ну скажем, OUR_SHOP, следует выполнить команду:

Еще лучше сразу при ее создании установить нужную кодировку (ведь по умолчанию в MySQL используется latin1). В итоге команда будет выглядеть так.

CREATE DATABASE our_shop CHARACTER SET cp1251

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

ALTER DATABASE our_shop CHARACTER SET cp1251

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

DROP DATABASE our_shop

Управление таблицами

Чтобы создать таблицу GOODS, на которой мы отрабатывали манипуляции с данными, потребуется составить команду примерно такого вида:

CREATE TABLE goods (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) NOT NULL UNIQUE,
price DECIMAL(10,2) NOT NULL,
unit_id INT DEFAULT 1,
country_id INT )


Разберем эту команду подробнее. Тип INT устанавливается для столбцов с целочисленными данными, тип VARCHAR(100) обеспечивает хранение строк с длиной не более 100 символов, DECIMAL(10,2) соответствует действительным числам с не более чем десятью знаками и точностью в два знака после запятой.

Столбец ID объявлен первичным ключом (PRIMARY KEY).

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

NOT NULL означает запрет на пустые значения в столбце, иными словами, гарантирует обязательность заполнения.

Команда DEFAULT задает значение по умолчанию — то, которое будет записываться в базу при добавлении новой строки, если не указано иное. В нашем случае она обеспечивает автоматическое объявление товара штучным (код = 1) в случае, если при добавлении новых строк не будет указан другой код.

Признак UNIQUE обеспечивает уникальность значений в колонке (в нашем случае — уникальность названий товаров).

Если в будущем вы захотите перенастроить объявленные командой CREATE столбцы таблицы, сделать это можно командой ALTER. Например, таблицу GOODS можно нарастить строчной колонкой REMARK (подкоманда ADD):

ALTER TABLE goods ADD remark VARCHAR(50)

Поработав с ней немного и убедившись, что 50 символов для примечания явно недостаточно, увеличиваем максимальный размер строки до 250 (блок CHANGE):

ALTER TABLE goods CHANGE remark remark VARCHAR(250)

Так как имя столбца мы не изменяли (новое совпадает со старым), то его просто повторяем в этой команде (как бы меняем само на себя).

И наконец, убедившись через какое-то время, что без примечания в товарном справочнике вполне можно обойтись, мы удаляем ставшую ненужной колонку (блок DROP):

ALTER TABLE goods DROP remark

Удалить таблицу целиком можно командой DROP:

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

Индексы и индексация таблиц

Представьте себе, что ваш приятель загадал число между 1 и 1000 и просит вас угадать его за минимальное число попыток, сообщая лишь о том, в большую или меньшую сторону вы ошиблись. Как вы поступите? Очевидно, предложите при первой попытке версию 500 (то есть начнете с середины). Если он ответит: «меньше», — предложите 250. Если «больше» — 750. Так, разбивая интервалы пополам, вы уложитесь в 10 попыток (ведь 2 10 > 10 3 ). Если бы приятель загадал число в пределах миллиарда, то количество попыток уложилось бы в 30 (2 30 > 10 9 ).

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

Как это делается практически? Поясню на примерах. Допустим, вас часто просят отобрать информацию о товарах российского производства. Чтобы по колонке COUNTRY_ID таблицы GOODS фильтрация производилась быстрее, создадим по ней индекс с именем IDX_GOODS_COUNTRY:

CREATE INDEX idx_goods_country ON goods(country_id)

Если в будущем вы передумаете использовать созданный индекс, то без труда его сможете удалить:

DROP INDEX idx_goods_country

Транзакции

Чтобы вы могли наглядно представить себе, что такое транзакция, и понять, зачем она нужна, приведу один простой пример. Представьте себе, что со счета Иванова на счет Петрова переводится сумма в 1000 рублей. Счета и того, и другого находятся в одной и той же базе данных. Как осуществляется перевод? Одна команда UPDATE уменьшает счет Иванова на 1000 руб., другая — на ту же сумму увеличивает счет Петрова.

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

В англоязычной литературе принято набор основных свойств транзакций обозначать мнемонической аббревиатурой ACID (в переводе — «кислота»). Буквами этого слова закодированы четыре свойства: Atomicity — неделимость, Consistency — согласованность, Isolation — изоляция, Durability — устойчивость). Транзакция неделима в том смысле, что представляет собой единое целое и является минимальным блоком алгоритма. Она согласованна, потому что не нарушает отношения между элементами данных или целостность базы данных даже при одновременной работе многих пользователей. Транзакция всегда изолирована, поскольку ее результаты не зависят от предыдущих или последующих транзакций. И наконец, устойчивость означает, что если транзакция завершена (зафиксирована), то внесенные ею изменения гарантированно сохранятся в базе данных.

Для объявления начала транзакции в MySQL используется стартовая команда:

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

Успешное выполнение всех операций завершается командой фиксации:

После завершения транзакции сделанные ею изменения сразу становятся видны во всех сессиях, работающих с базой данных.

Для отката изменений, сделанных в ходе выполнения транзакции, используется команда:

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

В таком режиме работает MySQL версий 3 и ниже или при установленном значении системной переменной AUTOCOMMIT=1. В режиме выключенной автофиксации (AUTOCOMMIT=0) каждое изменение в базе данных следует фиксировать явным образом (завершать командой COMMIT). Кому-то это может показаться утомительным, но именно такой режим обеспечивает целостную работу с данными, так как позволяет использовать всю мощь механизма транзакций. Именно в этом режиме работы мы можем переложить деньги Иванова на счет Петрова, не опасаясь, что они зависнут между счетами.

Одни произносят эту аббревиатуру как «эскуэль», другие (особенно американцы) — как «сиквел». Последнее произношение может показаться странным, если не знать историю создания языка.

А ведет эта история свое начало от той же самой фундаментальной работы Кодда. Для реализации его модели группа разработчиков из IBM предложила систему управления базами данных «System R» и язык запросов для обслуживания этой системы. Язык сначала назывался не SQL, а SEQUEL (Structured English Query Language). Такое название — не случайно. Начальный замысел создателей состоял в том, чтобы создать простой язык, максимально приближенный к бытовому английскому. Это и сейчас ощущается в синтаксисе SQL. Но, как и любой другой язык, SQL рос, развивался, ветвился на множество диалектов и, разумеется, усложнялся.

Этому противостояло другое начало — консервативное. Принимались стандарты языка (ANSI — c 1986 г., OSI — с 1987 г.). Так или иначе, идея о том, чтобы любая англоязычная кухарка могла управлять базами данных, оказалась невоплощенной. В современных реализациях языка (особенно таких, как SQL и PL/SQL для Oracle 10g) могут разобраться лишь профессиональные программисты. Тем не менее основные конструкции языка довольно просты и не требуют особой подготовки.

Что дальше?

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

Создание базы данных для WordPress

От автора

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

Что такое база данных сайта

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

Адрес сервера базы данных

Хостинг провайдер может установить сервер для базы данных у себя на сервере, в этом случае адрес сервера MySQL будет localhost. Но могут быть варианты. Например, хостинг MaкХост располагает свои сервера БД по адресам типа: vash_login.mysql.mchost.ru.

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

Теперь на практике рассмотрим, создание базы данных для WordPress.

Кстати, версия MySQL должна быть выше 5.0.

Создание базы данных для WordPress в панели ISPmanager

Авторизуйтесь в панели ISP вашего сервера. В левом, вертикальном меню найдите вкладку «Инструменты». Откройте пункт меню «Базы данных». На странице «Базы данных», жмете кнопку «Создать», в верхнем правом углу страницы.

Откроется форма для создания БД. Дайте базе данных

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

  • Создаете пользователя (для безопасности лучше нового);
  • Генерируете пароль базы данных.

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

Создаете базу данных.

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

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

Создание базы данных в панели DirectAdmin

Авторизуйтесь в панели DirectAdmin.

Откройте свой домен.

В меню панели (первая ее часть) ищите вкладку «Управление MySQL» . На вкладке, создаете базу данных для WordPress. База данных должна иметь: Имя базы, Имя пользователя и пароль доступа.

Все данные новой базы данных запоминаем. К этим записям добавляем адрес сервера MySQL.

Для контроля создания базы данных, со страницы меню панели переходим на вкладку «phpmyadmin» (она внизу). После авторизации, видим, что база данных создана, но она пустая.

Создание базы данных в панели в CPanel

CPanel очень популярна на импортных серверах.

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

Создание базы данных в панели в других панелях

Кроме стандартных панелей, многие хостинг компании разрабатывают свои административные панели.

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

Также вы должны иметь под рукой:

  • Название базы – её имя (name);
  • Пользователя, созданного для базы данных (user);
  • Пароль именно, базы данных (password);
  • Адрес размещения сервера MySQL (host).

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

Итоги урока Создание базы данных для WordPress

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

Часть 1. Постановка задачи, обзор используемых компонентов и создание БД для проекта

Серия контента:

Этот контент является частью # из серии # статей: Реальные проекты на PHP и MySQL. Разработка Web-форумов

Этот контент является частью серии: Реальные проекты на PHP и MySQL. Разработка Web-форумов

Следите за выходом новых статей этой серии.

Для примеров, представленных в статье, используется EasyEclipse for LAMPP версии 1.2.2.2 и встроенный PHP-browser. В качестве сервера приложений применяется LAMPP, описанный в предыдущих статьях.

Одним из наиболее эффективных способов привлечь (и самое главное удержать) внимание пользователей к некоторому Web-сайту или Интернет-магазину является создание Web-форума. Web-форум (далее просто форум) – это Web-приложение для организации общения посетителей Web-сайта. Сегодня форумы используются для решения самых разных задачах – от организации дискуссий на определенные темы до технической поддержки выпускаемых программных продуктов или аппаратных средств.

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

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

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

Первым шагом по реализации подобной функциональности должно стать создание базы данных Web-форума. В ней будет храниться информация об авторе, заголовке и содержимом сообщения. Хранение информации в базе данных должно быть организовано так, чтобы пользователь мог определить статус сообщения – является ли оно самостоятельной публикацией или служит ответом на другой «пост». В этом состоит основное отличие базы данных Web-форума от других вариантов, рассматриваемых в ранее опубликованных циклах.

Используемые компоненты

Стоит оговориться, что хотя удобный и красивый пользовательский интерфейс – это один из основных факторов, определяющих «выстрелит» форум или нет, в рассматриваемом примере не будут использоваться передовые дизайнерские решения из этой области. При создании интерфейса была установлена только одна цель: продемонстрировать, как реализовать требуемые функции с помощью PHP. Поэтому, в качестве «домашнего» задания и для создания законченного продукта можно добавить разработку современного GUI для получившегося Web-форума.

В ходе реализации проекта необходимо не только сохранять информацию об авторе и тексте сообщения, но и обеспечить навигацию по имеющимся темам, сообщениям и связям между ними. Как раз организация подобной иерархии в базе данных и представляет наибольшую сложность. В качестве стартовой точки необходимо рассматривать первоначальное сообщение, использованное для создания темы. Остальные сообщения можно рассматривать как «ответы» определенной степени родства на исходное сообщение. Если визуализировать подобное текстовое представление, то оно будет похоже на дерево, в котором ветвь порождает почки, те в свою очередь листья и т.д. Такая структура в программировании называется древовидной, и в случае с форумом можно в ней выделить элементы (nodes) (сообщения) и связи между элементами (отношения между сообщениями).

Далее остается только найти способ отображения такой структуры на реляционную СУБД (в рассматриваемом примере используется СУБД MySQL в составе пакета LAMPP — https://www.apachefriends.org/en/index.html) и механизм восстановления данных в случае их утраты. Интеграция Web-форума с СУБД позволит хранить сообщения в промежутках между их использованием, а, после создания несложного API на PHP пользователь получит возможность ими манипулировать.

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

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

  • родительский элемент текущего сообщения – сообщение, для которого текущее сообщение служит ответом;
  • ответ на любое сообщение в форуме – это его дочерний элемент;
  • самая первое сообщение, не имеющая родительского элемента – это корневой элемент.

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

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

Основы работы с MySQL

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

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

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

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

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

Для работы в системе MySQL необходимо создать пользователей с определенным набором полномочий. Для каждого пользователя необходимо установить учетную запись и пароль, которые не должны совпадать с системными. Для настройки учетных пользователей применяют команды GRANT и REVOKE (антоним) с параметрами.


Существует три основных типа полномочий. Ими наделяются обычные пользователи и администраторы. Кроме того существует ряд специальных полномочий. Задание таких полномочий связано с разрешениями на выполнение определенных SQL-команд. К их числу относятся команды SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE и другие.

Команда REVOKE – антоним команды GRANT и применяется для лишения полномочий. Например, команда REVOKE ALL PRIVILEGES, GRANT FROMuser_name лишит пользователя user_name всех полномочий, в том числе предоставленных функцией GRANT.

Для создания базы данных применяется команда

а для создания таблиц применяется команда

Чтобы выбрать используемую базу данных необходимо в командной строке MySQL ввести команду

Для просмотра таблиц в базе используется команда

а для просмотра имеющихся баз

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

Чтобы выбрать используемую базу данных необходимо в командной строке MySQL ввести команду

Для просмотра содержимого таблицы с именем my_table потребуется команда

а для вставки данных в эту таблицу используется команда:

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

Таблица 1. Параметры настройки, хранящиеся в файле php.ini
Как произносится SQL?
Параметр Описание Рекомендуемое значение
max_execution_time Сколько тактов CPU-секунд может задействовать SQL-сценарий 30
max_input_time как долго (в секундах) SQL-сценарий может ждать входных данных 60
memory_limit какое количество памяти (в байтах) может расходовать SQL-сценарий, прежде чем он будет убит 32M
output_buffering какое количество данных (в байтах) накапливается в буфере, прежде чем они будут отправлены клиенту 4096

Cоздание базы данных для форума

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

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

  • postid – идентификатор сообщения; должен быть уникальным;
  • poster – автор сообщения;
  • parent – идентификатор родительского сообщения (такой же postid);
  • title – заголовок;
  • posted – время и дата публикации сообщения;
  • message – содержимое.

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

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

Известно, что в MySQL поиск записей фиксированного размера выполняется быстрее, чем переменного. Поэтому при использовании данных переменной длины обязательно нужно организовать индексы, которые будут задействоваться при поиске и увеличат скорость выполнения запросов. Однако у индексов есть и «побочный» эффект: они должны пересчитываться при добавлении/удалении/обновлении записей, и так как все эти действия происходят на форумах постоянно, возможна уменьшение быстродействия уже из-за частого обновления индексов.

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

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

Листинг 1. SQL-сценарий для создания базы данных форума

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

где create_mydata.sql – это файл с SQL-сценарием из листинга 1.

Также можно воспользоваться надстройкой phpMyAdmin (см. рисунок 1.).

Рисунок 1. Выполнение SQL-сценария с помощью phpMyAdmin

Отображение форума в PHP-браузере, встроенном в Eclipse IDE , можно увидеть на рисунке 2.

Рисунок 2. PHP-проект форума в Eclipse >Кликните, чтобы увидеть увеличенное изображение

Заключение

Хотя использование «коробочных» продуктов (например, phpBB, invision Power Board) позволяет быстро развернуть форум на любом Интернет-ресурсе, разработка индивидуального решения позволяет лучше интегрировать форум с основным сайтом, учесть особенности целевой аудитории и заодно повысить навыки разработки Web-приложений.

В этой статье из цикла «Реальные проекты на PHP и MySQL. Разработка Web-форумов» описаны основные характеристики и принципы реализации Web-форумов. Также в ней представлен пример форума, который будет разрабатываться в следующих статьях, и выполнен первый этап работ по реализации форума – создана база данных для хранения сообщений.

Ресурсы для скачивания

Комментарии

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

Проектирование информационной системы для ведения блога Текст научной статьи по специальности « Автоматика. Вычислительная техника»

Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Мясникова Н.А., Курин Н.Д.

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

Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Мясникова Н.А., Курин Н.Д.,

Текст научной работы на тему «Проектирование информационной системы для ведения блога»

В перспективе планируется выпуск новой версии программного инструментария UFO-toolkit, где будут автоматизированы все описанные возможности системно-объектного моделирования.

1. Емельянов А. А., Власова Е. А. Имитационное моделирование экономических процессов / Имитационное моделирование. Теория и практика. Четвертая всероссийская научнопрактическая конференция по имитационному моделированию и его применению в науке и промышленности (ИММОД-2009), Санкт-Петербург, 2009.

2. Маторин С.И., Попов А.С., Маторин В.С. Моделирование организационных систем в свете нового подхода «Узел-Функция-Объект» // Научно-техническая информация. Сер. 2. — 2005. -№1.-С. 1-8.

3. Маторин С.И., Зимовец О.А., Жихарев А.Г. О развитии технологии графоаналитического моделирования бизнеса с использованием системного подхода «Узел-Функция-Объект» // Научно-техническая информация. Сер. 2. — 2007. — №11. — С. 10-17.

4. Маторин С.И. О новом методе системологического анализа, согласованном с процедурой объектно-ориентированного проектирования. Часть 2 // Кибернетика и системный анализ. -2002. -№1.-С. 118-130.

5. Жихарев А.Г., Маторин С.И., Маматов Е.М., Смородина Н.Н. О системно-объектном методе представления организационных знаний // Научные ведомости Белгородского государственного университета. Сер. История. Политология. Экономика. Информатика. -2013. — № 8 (151). — Выпуск 26/1. — С. 137-146.

6. Abadi Martin and Luca Cardelli A Theory of Objects. Springer-Verlag, 1996.

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ВЕДЕНИЯ БЛОГА

Мясникова Нелли Александровна, доцент, Южно-Российский государственный политехнический университет (Новочеркасский политехнический институт) имени М.И. Платова, Россия,

Курин Николай Дмитриевич, студент, Южно-Российский государственный политехнический университет (Новочеркасский политехнический институт) имени М.И. Платова, Россия,

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

От обычных дневников блоги отличаются своей публичностью: блоги предполагают сторонних читателей, которые могут оставлять комментарии как непосредственно под записью, так и в своих собственных блогах. Можно выделить еще одну особенность -простоту добавления новых записей. Пользователь просто обращается к веб-серверу, происходит идентификация, после чего пользователь просто добавляет еще одну запись. Сервер представляет информацию как последовательность сообщений, помещая самые свежие сообщения вверху [1].


Можно выделить следующие функции блогов:

• функция сплочения и удержания социальных связей;

• функция саморазвития, или рефлексии;

• продвижение товаров и услуг.

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

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

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

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

1. Поддержка индивидуальности объектов.

2. Поддержка инкапсуляции.

3. Поддержка классов.

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

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

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

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

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

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

Построение объектно-ориентированной базы данных происходит в несколько этапов

• изучение предметной области — определение области работы БД и определение примерного функционала;

• концептуальное проектирование — конструирование модели, не зависящей от физической реализации;

• логическое проектирование — конструирование модели на основе выделенных типов данных;

• физическое проектирование — физическое развертывание БД.

Теперь применим каждый из этапов к информационной модели нашего блога:

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

Концептуальное проектирование сводится к построению концептуальной схемы. На рис. 1 представлены все выделенные сущности и их атрибуты. Для описания пользователей была выделена сущность User. Эта сущность должна содержать следующие атрибуты: Name — имя пользователя, Family — фамилия пользователя, NickName — псевдоним пользователя, BirthDate — дата рождения пользователя, Password — пароль пользователя, Info -дополнительная информация о пользователе (интересы, музыкальные предпочтения и т.д.). В блоге могут быть как сам автор блога, так и его читатели, при этом блоггер и читатели имеют разные права. Для определения, «кто есть кто», создана сущность Level. Эта сущность имеет следующие атрибуты: AccessLevel — уровень доступа, доступный конкретному

пользователю. Автор блога может создавать записи. Для представления записей была создана сущность Post. Эта сущность содержит следующие атрибуты: Title — название (заголовок) для записи, Date — дата публикации записи, Content — содержание записи. Все пользователи могут комментировать записи, которые также являются сущностями. В связи с этим была выделена ещё одна сущность — Comment. Эта сущность должна иметь следующие атрибуты: Date — дата публикации комментария, Content — содержание комментария. Также, каждая запись может иметь один или несколько хэш-тэгов. В связи с этим была выделена ещё одна сущность — Tag, имеющая следующие атрибуты: ListOfTags — список тегов.

Рис. 1 — Концептуальная модель 59

Когда концептуальная модель построена, необходимо создать логическую модель. Построение логической модели сводится к тому, чтобы выделить и абстрагировать некоторые общие свойства разных сущностей. Учитывая то, что сущности Post и Comment имеют одинаковые атрибуты Date (дата публикации) и Content (данные), можно выделить ещё один абстрактный класс ContentDateObject, который будет иметь атрибуты Date и Content. Таким образом, получается, что классы Comment и Post наследуются от ContentDateObject. Нужно отметить, что все атрибуты класса Comment наследуются от класса ContentDateObject, то есть он не имеет собственных атрибутов.

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

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

удаления записей, а также комментирование записей — как своих, так и чужих. Все сформулированные требования показаны на рис. 3.

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

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

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

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

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

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

Каждый пользователь может прокомментировать любую запись, как посчитает нужным. В базе данных каждый комментарий представляется экземпляром класса Comment. Когда пользователь пишет комментарий и жмет кнопку «Добавить комментарий», происходит отправка введенных данных на сервер. Сервер обрабатывает данные, а именно: кем, когда, и к какой записи он был оставлен, а также непосредственно содержание комментария, после чего он заносится в базу данных. Когда пользователь жмет «Показать комментарии», на сервер отправляются сведения о том, для какой именно записи должны быть загружены комментарии. Происходит получение всех комментариев, относящихся к этой записи, после чего они в отсортированном по дате и времени виде отправляются на клиентскую машину пользователя. Соответственно, пользователь их видит и может прочесть.

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

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

1. Объектно-ориентированная база данных — Википедия. URL:

Ьйр8://щ.-мк1реб1а.ощ/-мк1/Объектно-ориеитироваииая база данных (дата обращения: 21.04.2015)

2. Блог — Википедия. URL: Ьйр8://ги.-мк1реб1а.от/-мк1/Блог (дата обращения: 21.04.2015)

3. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. — ДМК Пресс Издательство, 2008 г. — 496 с.

4. Байдачный С.С. Silverlight 4: Создание насыщенных Web-приложений СОЛОН-Пресс Издательство, 2010 г. -288 с.

5. Батоврин В.К. Системная и программная инженерия. Словарь-справочник: учебное пособие для вузов. — ДМК Пресс Издательство, 2010 г. — 280 с.

ИЗУЧЕНИЕ И ОЦЕНКА ПОХОДОВ К РАЗРАБОТКЕ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

Искра Наталья Александровна, магистр технических наук, ассистент кафедры ЭВМ, Белорусский государственный университет информатики и радиоэлектроники, Республика Беларусь, Минск,

Макоед Виктор Николаевич, студент, Белорусский государственный университет информатики и радиоэлектроники, Республика Беларусь, Минск, vmakoed@gmail.com Куница Евгений Юрьевич, студент, Белорусский государственный университет информатики и радиоэлектроники, Республика Беларусь, Минск, kunitsa.evgeniy@gmail.com

На сегодняшний день существует большое количество инструментов разработки графического интерфейса пользователя (Graphical User Interface, GUI), предлагающих создание программ на различных языках программирования и реализующих различные подходы к созданию интерфейса. В процессе изучения и практического освоения новой технологии обучающемуся приходится сталкиваться с разнообразными задачами, и очень важно систематически представить приёмы их решения, следуя принципу «от простого — к сложному». Следует отметить, что и в будущей профессиональной деятельности обучающийся должен уметь оперативно оценивать различные подходы к реализации GUI для того, чтобы решать поставленные задачи максимально эффективно.

Существуют подходы к сравнению технологий по созданию GUI на основе метрик, оценивающие, например, системные требованиям к запуску приложений и занимаемой памяти [1]. Однако для изучения новой технологии важно в первую очередь сопоставить инструменты с точки зрения самого процесса разработки, а именно — написания исходного кода приложений. Для этого могут использоваться некоторые «типовые задачи», которые часто встречаются на практике, например проект 7GUI [2].

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

В рамках проекта уже было проведено сравнение объектно-ориентированного и функционального подходов к реализации GUI [3]. Мы, в свою очередь, внесли свой вклад в проект в виде сравнения двух объектно-ориентированных кроссплатформенных подходов [4]

1. Исследуемые задачи и подходы


Для оценки эффективности объектно-ориентированных кроссплатформенных фреймворков Qt[5] и JavaFX[6] были спроектированы и разработаны приложения CRUD и

10 бесплатных тем и плагинов для создания базы знаний в WordPress

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

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

WP Knowledge Base

Потрясающая тема WP Knowledge Base — одна из самых старых и наиболее широко поддерживаемых тем. Она была разработана более пяти лет назад и отлично работает с плагином сообщества bbPress.

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

Последний релиз поддерживал WordPress 3.5, а мы уже дошли до версии 4.x (и эта цифра продолжает расти!).

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

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

MyKnowledgeBase

Это очень простая тема без лишних наворотов. MyKnowledgeBase является абсолютно бесплатной и разработана под последнюю версию WordPress.

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

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

WikiWP

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

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

Эта тема ещё и SEO-дружелюбна, но может быть использована как внутренняя база знаний, если вы хотите спрятать её от поисковых роботов.

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

MyWiki

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

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

Мне больше нравится эта тема, нежели описанная выше, так как MyWiki действительно работает как организованная база знаний.

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

WP Knowledgebase

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

Имейте в виду, что у него не много настроек в плане оформления, так что вам придётся размещать рубрики/ссылки с учётом этого. Этот плагин пригодится, если вы начинаете с простой темы и потом дорабатываете сайт.

Функции плагина WP Knowledgebase включают в себя предиктивный поиск (автозаполнение), редактор drag-and-drop, отзывчивый дизайн и ещё много всего.

DW Knowledge Base

Другой замечательный плагин — это DW Knowledge Base, созданный ребятами из DesignWall.

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

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

Very Simple Knowledge Base

Полностью соответствует своему названию плагин Very Simple Knowledge Base (Очень Простая База Знаний), выпущенный в бесплатной версии, которую можно найти в разделе плагинов WP.

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

Эти списки ссылок разделены по категориям и включают страницы «архива» для всех статей базы знаний.

Обратите внимание, что дизайн у этого плагина очень ограничен, так что вам помогут знания CSS.

Ultimate FAQ

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

Плагин Ultimate FAQ даёт возможность создавать неограниченные типы записей вопрос/ответ с пользовательскими метками и рубриками. Он также поддерживает функцию поиска на Ajax, где тематические разделы автоматически рекомендуются и ведут прямо на нужную страницу.

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

Knowledgebase by WebberZone

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

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

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

Knowledge Center

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

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

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

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

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

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

Для отправки комментария вам необходимо авторизоваться.

Структура и таблицы базы данных WordPress


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

Сегодня моя новая статья будет посвящена базе данных MySQL, которая является неотъемлемой частью платформы WordPress. Поскольку WordPress самостоятельно взаимодействует с базой данных, то обычные пользователи не должны сильно волноваться о её структуре. Однако, вам может быть интересно узнать, как WordPress хранит свои данные и зависимости, если пишете свой плагин.

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

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

Таблицы, из которых состоит база данных WordPress

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

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

  1. wp_commentmeta
  2. wp_comments
  3. wp_links
  4. wp_options
  5. wp_postmeta
  6. wp_posts
  7. wp_termmeta
  8. wp_terms
  9. wp_term_relationships
  10. wp_term_taxonomy
  11. wp_usermeta
  12. wp_users

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

  • Установлена другая версия WordPress. На момент последнего редактирования текущей статьи актуальной версией является 5.0. Настоятельно рекомендую своевременно обновлять CMS.
  • Установлены плагины, которые создали в базе данных свои таблицы. Плагины также меняют содержимое таблиц, добавляя новые поля, строки и т.д.
  • В процессе установки WordPress был изменён стандартный префикс таблиц.

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

Описание и предназначение таблиц базы данных

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

Таблица wp_commentmeta

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

Таблица wp_comments

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

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

Таблица wp_links

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

Теперь эта функция устарела, но при необходимости её можно включить с помощью плагина Links Manager.

Таблица wp_options

Хранит основные настройки WordPress, в том числе параметры, доступные для изменения в консоли администрирования. Кстати, таблица wp_options очень интересна для изучения, но зачастую после установки и последующего удаления плагинов содержит лишние строки. У меня есть отличное руководство по чистке базы данных от «мусора».

Таблица wp_postmeta

Хранит огромное количество данных о записях и страницах сайта: информацию о прикреплённых файлах (изображения, документы, видео), данные заполняемых полей при создании или редактировании записей. Некоторые плагины могут добавлять свою собственную информацию в эту таблицу. Например, плагин All in One SEO Pack хранит здесь Title, Description и Keywords.

Таблица wp_posts

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

Таблица wp_termmeta

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

Таблица wp_terms

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

Таблица wp_term_relationships

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

Таблица wp_term_taxonomy

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

Таблица wp_usermeta

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

Таблица wp_users

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

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

Проектирование БД для блога

Я новичек в программировании (за плечами собственно только знание основ программирования,
изученные на примере языка «С»), хочу уйти в web, и сейчас самостоятельно изучаю PHP.
Как известно обучаться лучше всего на практике поэтому решил делать блог.
В данный момент моя проблема в том что я не знаю принципов проектирования БД вообще и
для веб приложений в частности.

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

08.02.2011, 14:28

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

Создание админ панели (не для блога)
Собственно выучил html и css. Для себя начал делать проект, вроде как всё оформил, но не хватает.

Генерация страниц для каждого поста блога
Есть база данных с такими полями id (уникальный номер статьи), title (заголовок статьи), date (дата.

Делаю по урокам простую CMS для блога, но выводит ошибку
Такая проблема делал по урокам cms, до этого учил основы и разбирался. Хотел начать с простенького.

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

Дизайн базы данных для блога

Я ищу лучший способ создать базу данных для простого блога. Моя идея:

  • Стол сообщений — содержит идентификатор, содержимое и т.д.
  • Категории — содержит идентификатор категории, имя, имя ссылки (простое имя, используемое, например, в маршрутах),
  • Теги — идентификатор тега, имя тега, имя ссылки,
  • CategoriesMap — содержит идентификатор и идентификатор категории, должность может иметь несколько категорий,
  • TagMap — как указано выше.

Это хорошее решение? Я использую Symfony3 с Doctrine и MySQL.

В дополнение к приведенным выше таблицам я рекомендую вам добавить следующие таблицы:

    Персонал: таблица для персонала, которая может включать в себя такие поля, как: >

Мастер Йода рекомендует:  Как разбивать запрос на страницы (постраничный вывод данных) PHP
Добавить комментарий