Как создается бд. Основы создания баз данных MySQL. Значение по умолчанию

Базы данных на ПК развивались по направлению от настольных (desktop), или локальных приложений, когда реально с БД могло работать одно приложение, до систем коллективного доступа к БД.
Локальное приложение устанавливалось на единичном ПК; там же располагалась и база данных (БД), с которой работало данное приложение. Однако необходимость коллективной работы с одной и той же БД повлекло за собой перенос БД на сервер. Приложение, работающее с БД, располагалось также на сервере.

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

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

Локальные базы данных;

Архитектура "файл-сервер";

Архитектура "клиент-сервер";

Многозвенная архитектура.

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

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

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

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

Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты database desktop фирмы borland для файлов paradox или dbase); подобная возможность облегчается тем обстоятельством, что, фактически, у локальных СУБД база данных – понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.

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

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

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

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

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

Функциями приложения-клиента являются:

Посылка к серверу запросов;

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

Реализация интерфейса пользователя.

sql-сервер должен быть загружен на момент принятия запроса клиента. Функциями сервера БД являются:

Прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;

Управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;

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

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

В архитектуре "клиент-сервер" используются так называемые "удаленные" (или "промышленные") СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.
К разряду промышленных СУБД принадлежат oracle, informix, sybase, ms sql server, db2, interbase и ряд других.

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

Механизмы доступа

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

Существует несколько способов доступа к данным из средств разработки и клиентских приложений.
Подавляющее большинство СУБД содержит в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (application programming interface, api) для доступа к данным этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов базы данных (БД), а в случае серверных СУБД инициируют передачу запросов серверу баз данных и получение от сервера результатов выполнения запросов или кодов ошибок, интерпретируемых клиентским приложением. Библиотеки, содержащие api для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения.

В последнее время windows-версии клиентского программного обеспечения наиболее популярных серверных СУБД, в частности microsoft sql server, oracle, informix, содержат также СОМ-серверы, предоставляющие объекты для доступа к данным и метаданным.
Использование клиентского api (или клиентских СОМ-объектов) является наиболее очевидным способом манипуляции данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только СУБД этого производителя, и замена ее на другую повлечет за собой переписывание значительной части кода клиентского приложения – клиентские api и объектные модели не подчиняются никаким стандартам и различны для различных СУБД.

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

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

open database connectivity (odbc). ole db. activex data objects (ado). borland database engine (bde).

Универсальные механизмы odbc, ole db и ado фирмы microsoft представляют собой по существу промышленные стандарты. Что касается механизма доступа к данным bde фирмы borland, то он так и не стал промышленным стандартом, однако до недавнего времени применялся довольно широко, поскольку до выхода delphi 5 был практически единственным универмальным механизмом доступа к данным, поддерживаемым средствами разработки borland на уровне компонентов и классов

Что такое sql?

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

Tutorial

Всем привет! Меня зовут Олег и я программист-любитель под Android. Любитель потому что в данный момент я зарабатываю деньги программированием в совсем другом направлении. А это хобби, которому я посвящаю свое свободное время. К сожалению у меня нет знакомых программистов под Android и все свои базовые знания я черпаю либо из книг, либо из интернета. Во всех тех книжках и статьях в интернете, которые я читал, созданию базы данных для приложения отводится крайне мало места и по сути все описание сводится к созданию класса являющегося наследником SQLiteOpenHelper и последующему внедрению SQL кода в Java код. Если не считать, что мы получаем плохо читаемый код (а если в нашем приложении появляется больше 10 таблиц, то вспоминать все эти взаимосвязи между таблицами тот еще ад), то в принципе жить можно конечно, но как-то совершенно не хочется.
Забыл сказать самое главное, можно сказать что это моя проба пера тут. И так поехали.

О вечном вопросе: почему?

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

Если в нашем приложении больше 5 таблиц, то уже было бы не плохо использовать какой-нибудь инструмент для визуального проектирования архитектуры БД. Поскольку для меня это хобби, то и использую я абсолютно бесплатный инструмент под названием Oracle SQL Developer Data Modeler (скачать его можно ).

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

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

Данный инструмент является аналогом таких известных продуктов как SQL Naviagator, Toad etc. Но как следует из названия, заточен он под работу с SQLite. Он позволяет визуально создать БД и получить DDL код создаваемых таблиц. Кстати, он также позволяет создавать представления (View), которые вы тоже при желании можете использовать в своем приложении. Не знаю насколько правильный подход использования представлений в программах для Android, но в одном из своих приложений я использовал их.

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

О директориях db и data

Внутри директории assets я создал две директории db_01 и data_01 . Цифры в названиях директорий соответствуют номеру версии моей БД с которой я работаю. В директории db у меня хранятся сами SQL скрипты создания таблиц. А в директории data хранятся данные необходимые для начального заполнения таблиц.

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

Private static final String TAG = "RoadMap4.DBHelper"; String mDb = "db_"; String mData = "data_"; Context mContext; int mVersion; public DBHelper(Context context, String name, int version) { super(context, name, null, version); mContext = context; mVersion = version; }
Теперь метод onCreate и тут становится уже интереснее:

@Override public void onCreate(SQLiteDatabase db) { ArrayList tables = getSQLTables(); for (String table: tables){ db.execSQL(table); } ArrayList> dataSQL = getSQLDatas(); for (HashMap hm: dataSQL){ for (String table: hm.keySet()){ Log.d(TAG, "insert into " + table + " " + hm.get(table)); long rowId = db.insert(table, null, hm.get(table)); } } }
Логически он разделен на два цикла, в первом цикле я получаю список SQL - инструкций для создания БД и затем выполняю их, во втором цикле я уже заполняю созданные ранее таблицы начальными данными. И так, шаг первый:

Private ArrayList getSQLTables() { ArrayList tables = new ArrayList<>(); ArrayList files = new ArrayList<>(); AssetManager assetManager = mContext.getAssets(); String dir = mDb + mVersion; try { String listFiles = assetManager.list(dir); for (String file: listFiles){ files.add(file); } Collections.sort(files, new QueryFilesComparator()); BufferedReader bufferedReader; String query; String line; for (String file: files){ Log.d(TAG, "file db is " + file); bufferedReader = new BufferedReader(new InputStreamReader(assetManager.open(dir + "/" + file))); query = ""; while ((line = bufferedReader.readLine()) != null){ query = query + line; } bufferedReader.close(); tables.add(query); } } catch (IOException e) { e.printStackTrace(); } return tables; }
Тут все достаточно просто, мы просто читаем содержимое файлов, и конкатенируем содержимое каждого файла в элемент массива. Обратите внимание, что я произвожу сортировку списка файлов, так как таблицы могут иметь внешние ключи, а значит таблицы должны создаваться в определенном порядке. Я использую нумерацию в название файлов, и с помощью нею и произвожу сортировку.

Private class QueryFilesComparator implements Comparator{ @Override public int compare(String file1, String file2) { Integer f2 = Integer.parseInt(file1.substring(0, 2)); Integer f1 = Integer.parseInt(file2.substring(0, 2)); return f2.compareTo(f1); } }
С заполнением таблиц все веселей. Таблицы у меня заполняются не только жестко заданными значениями, но также значениями из ресурсов и UUID ключами (я надеюсь когда-нибудь прийти к сетевой версии своей программы, что бы мои пользователи могли работать с общими данными). Сама структура файлов с начальными данными выглядит так:

Несмотря на то, что файлы у меня имеют расширение sql, внутри не sql код а вот такая штука:

Prioritys
pri_id:UUID:UUID

pri_name:string:normal
pri_color:color:colorGreen
pri_default:int:1
prioritys
pri_id:UUID:UUID
pri_object:string:object_task
pri_name:string:hold
pri_color:color:colorBlue
pri_default:int:0
prioritys
pri_id:UUID:UUID
pri_object:string:object_task
pri_name:string:important
pri_color:color:colorRed
pri_default:int:0
prioritys
pri_id:UUID:UUID

pri_name:string:normal
pri_color:color:colorGreen
pri_default:int:1
prioritys
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:hold
pri_color:color:colorBlue
pri_default:int:0
prioritys
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:important
pri_color:color:colorRed
pri_default:int:0

Структура файла такая: я выполняю вызов функции split(":") применительно к строчке и если получаю что ее размер равен 1 то значит это название таблицы, куда надо записать данные. Иначе это сами данные. Первое поле это название поля в таблице. Второе поле тип, по которому я определяю что мне надо в это самое поле записать. Если это UUID - это значит мне надо сгенерировать уникальное значение UUID. Если string значит мне надо из ресурсов вытащить строковое значение. Если color, то опять-таки, из ресурсов надо вытащить код цвета. Если int или text, то я просто преобразую данное значение в int или String без каких либо телодвижений. Сам код выглядит вот так:

Private ArrayList> getSQLDatas() { ArrayList> data = new ArrayList<>(); ArrayList files = new ArrayList<>(); AssetManager assetManager = mContext.getAssets(); String dir = mData + mVersion; try { String listFiles = assetManager.list(dir); for (String file: listFiles){ files.add(file); } Collections.sort(files, new QueryFilesComparator()); BufferedReader bufferedReader; String line; int separator = 0; ContentValues cv = null; String fields; String nameTable = null; String packageName = mContext.getPackageName(); boolean flag = false; HashMap hm; for (String file: files){ Log.d(TAG, "file db is " + file); bufferedReader = new BufferedReader(new InputStreamReader(assetManager.open(dir + "/" + file))); while ((line = bufferedReader.readLine()) != null){ fields = line.trim().split(":"); if (fields.length == 1){ if (flag == true){ hm = new HashMap<>(); hm.put(nameTable, cv); data.add(hm); } // наименование таблицы nameTable = line.trim(); cv = new ContentValues(); continue; } else { if (fields.equals("UUID")){ cv.put(fields, UUID.randomUUID().toString()); } else if (fields.equals("color") || fields.equals("string")){ int resId = mContext.getResources().getIdentifier(fields, fields, packageName); Log.d(TAG, fields + " " + resId); switch (fields){ case "color": cv.put(fields, resId); break; case "string": cv.put(fields, mContext.getString(resId)); break; default: break; } } else if (fields.equals("text")){ cv.put(fields, fields); } else if (fields.equals("int")){ cv.put(fields, Integer.parseInt(fields)); } } flag = true; } bufferedReader.close(); } } catch (IOException e) { e.printStackTrace(); } return data; }

2017-06-21

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

Здравствуйте уважаемый посетитель!

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

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

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

В данной статье мы создадим базу данных на локальном веб-сервере Denwer и на хостинге, на котором размещен наш сайт.

Зачем нужна база данных
Что из себя представляет база данных MySQL
Создаем базу данных на локальном веб-сервере Denwer
Создаем базу данных на хостинге

Зачем нужна база данных

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

разработка дизайн-макета;
формирование веб-страниц с помощью HTML и CSS;
создание динамического сайта с использованием PHP;
адаптация сайта под мобильные устройства с помощью медиа-запросов;
размещение сайта в интернете;

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

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

наполнение контентом;
работа с формами;
учет информации о клиентах;
учет информации о заказах;
учет информации о полученных комиссионных;
учет информации об отправленных и полученных e-mail;
оптимизация;

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

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

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

Что из себя представляет база данных MySQL

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

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

Эти таблицы могут иметь в зависимости от объема разное количество строк (записей) и столбцов (полей). Первый столбец обычно определяет уникальный идентификатор записи (его обычно называют "id"), а остальные поля назначаются в зависимости от их количества.

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

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

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

Здесь видно, что таблица состоит из 6-ти столбцов и определенного количества строк, в зависимости от размера заданного периода (в данном случае в таблице имеется 35539 последних записей). Каждая строка содержит данные по дате, времени, количестве посещений за сутки, ip-адрес пользователя и наименование хоста.

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

К примеру, можно сделать SQL запрос, который переберет по порядку все значения id, и таким образом позволит извлечь данные из всей таблицы. А можно, сделав запрос по конкретному ip-адресу, отсортировать и проанализировать посещения, которые были сделаны именно с него.

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

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

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

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

Создаем базу данных на локальном веб-сервере Denwer

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

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

Для этого, в начале, набрав в адресной строке браузера "http://localhost/Tools/phpMyAdmin/" откроем главную страницу phpMyAdmin.

Следует отметить, что открыть этот интерфейс можно и другим способом - через ссылку на главной страница Денвера, как показано на следующем скриншоте, предварительно набрав в браузере "http://localhost/denwer/".

А далее, перейдя в соответствующий раздел, создадим базу данных. Для этого достаточно ввести ее наименование, (назовем ее, например, "avtobezugona") и необходимую кодировку, в нашем случае, это будет "ult8_general_ci"

Вот и все, наша база с именем "avtobezugona" создана, о чем свидетельствуют соответствующие поля в перечне баз данных раздела "Базы данных" и в главном меню phpMyAdmin.

Создаем базу данных на хостинге

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

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

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

Теперь можно перейти непосредственно в редактор PhpMyAdmin и установить необходимую кодировку базы данных.

Но, для того, чтобы войти в приложение PhpMyAdmin следует ввести в соответствующие поля данные, которые были определены при создании базы и подтверждены на завершающем этапе (рис.7).

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

Следующая сатья:

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

1. Подготовка базы данных. Создаём первую таблицу в БД MySQL

Создаём новую базу данных, например «mysite». Лично я привык работать с кодировкой UTF-8, по-этому сразу оговорюсь: проследите, чтобы все текстовые файлы сайта, сама база, таблицы и поля таблиц были в одной кодировке.
В новой базе делаем таблицу. Назовём её «pages». В этой таблице будут храниться статические страницы будущего сайта и информация о них. Таблица должна содержать следующие поля:

page_id - идентификатор страницы (SMALLINT, primary key, auto_increment);
page_alias - псевдоним страницы для строки адреса ЧПУ (VARCHAR, 255);
page_title - название страницы в окне браузера (VARCHAR, 255);
page_meta_d - мета описание страницы для тега meta description (VARCHAR, 255);
page_meta_k - мета ключевые слова для тега meta keywords (VARCHAR, 255);
page_h1 - заголовок страницы (VARCHAR, 255);
page_s_desc - краткое описание материала, например если материалы сайта будут в виде блога (TEXT);
page_content - основной текст страницы, который будет выводиться в центральную колонку сайта (TEXT);
page_publish - содержит «Y» - если страница опубликована, или «N» - если она скрыта (CHAR, по умолчанию «Y»).

Сразу после создания таблицы вставляем в неё значения для главной страницы сайта. В поле «page_alias» для главной страницы предлагаю вставить значение «home». Метатеги - соответственно тематике всего сайта. Таким же образом можно посоздавать другие страницы, например «О компании» с алиасом «about» и своими метатегами, или «Контакты» с алиасом «contacts» и т.д.

2. Создаём файл конфигурации сайта

В корневой папке сайта, которая должна быть пуста на данном этапе, создаём папочку «cfg», в ней с помощью.htaccess закрываем доступ директивой «deny from all». Создаём файл core.php следующего содержания:

// MYSQL
class MyDB
{
var $dblogin = "root"; // ВАШ ЛОГИН К БАЗЕ ДАННЫХ
var $dbpass = ""; // ВАШ ПАРОЛЬ К БАЗЕ ДАННЫХ
var $db = "mysite"; // НАЗВАНИЕ БАЗЫ ДЛЯ САЙТА
var $dbhost="localhost";

Var $link;
var $query;
var $err;
var $result;
var $data;
var $fetch;

Function connect() {
$this->link = mysql_connect($this->dbhost, $this->dblogin, $this->dbpass);
mysql_select_db($this->db);
mysql_query("SET NAMES utf8");
}

Function close() {
mysql_close($this->link);
}

Function run($query) {
$this->query = $query;
$this->result = mysql_query($this->query, $this->link);
$this->err = mysql_error();
}
function row() {
$this->data = mysql_fetch_assoc($this->result);
}
function fetch() {
while ($this->data = mysql_fetch_assoc($this->result)) {
$this->fetch = $this->data;
return $this->fetch;
}
}
function stop() {
unset($this->data);
unset($this->result);
unset($this->fetch);
unset($this->err);
unset($this->query);
}
}

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

Если Вы работаете в среде Windows, я могу порекоммендовать использовать редактор . В этом редакторе есть нумерация строк, и он легко переводит текст из одной кодировки в другую. ВНИМАНИЕ! Если Вы работаете в кодировке UTF-8 - конвертируйте файлы в UTF-8 without BOM - это поможет избежать проблем в будущем.

3. Создаём index.php - главный контроллер сайта

Файл конфигурации создан. Теперь в корневой папке сайта создаём index.php - это и будет основной скрипт сайта, своего рода «главный контроллер». Содержание файла index.php:

define("INDEX", ""); // УСТАНОВКА КОНСТАНТЫ ГЛАВНОГО КОНТРОЛЛЕРА

Require_once($_SERVER."/cfg/core.php"); // ПОДКЛЮЧЕНИЕ ЯДРА

// ПОДКЛЮЧЕНИЕ К БД
$db = new MyDB();
$db->connect();

// ГЛАВНЫЙ КОНТРОЛЛЕР
switch ($_GET) {
case "page":
include($_SERVER."/com/page.php");
break;
default:
include($_SERVER."/com/home.php");
break;
}

Include ($_SERVER."/template.php");
$db->close();

Переменная $_GET будет указывать главному контроллеру какой компонент сайта загружать при запросе. Сейчас в нашем сайте предусмотрено только два компонента: «страница» и «главная страница» (в принципе можно обойтись и одним компонентом вывода обычной страницы, но часто вид главной страницы сайта отличается от обычных страниц пунктов меню). Логика работы главного контроллера такова: из URL строки извлекается название нужного компонента (значение переменной $option), в зависимости от его значения подключается файл самого компонента (содержится в папке /com). Файл компонента выполняет все необходимые работы, извлекает из базы данные и записывает их в переменные, для передачи в шаблон дизайна. В самом конце подключается файл дизайна сайта, в который и передаются все переменные и данные, извлечённые в компонентах. Это звучит намного сложнее, чем работает.

4. Создаём компонент вывода обычной страницы

В корне сайта создаём папочку «com» - в ней будут храниться файлы компонентов. Компонент сайта, в моём понимании - это файл, в котором происходит обработка данных для разных разделов сайта. Например компонент обычной страницы извлекает из базы данных название, описание и текст материала, и записывает их в переменные $title, $meta_d, $meta_k, $content и др. Эти данные потом передаются в шаблон дизайна (под каждый компонент можно создавать свой шаблон дизайна) и выводятся пользователю в виде HTML-страницы. Например, компонент каталога, который можно создать в будущем, выполнял бы почти то же самое, но с данными про товары - а там своя специфика, другие поля в таблице, итд. По-этому для каждого функционального раздела сайта стоит создавать отдельный компонент. В схеме MVC (Model-View-Controller) компонент выполняет роль модели.

Создаём в папке «com» файл «page.php». Содержимое файла следущее:

/* КОМПОНЕНТ СТРАНИЦЫ */
$alias = $_GET;
$query = "SELECT * FROM pages WHERE page_alias="".$alias."" AND page_publish="Y" LIMIT 1";
$db->run($query);
$db->row();
// ПЕРЕМЕННЫЕ КОМПОНЕНТА
$id = $db->data;
$alias = $db->data;
$title = $db->data;
$h1 = $db->data;
$meta_d = $db->data;
$meta_k = $db->data;
$s_desc = $db->data;
$component = $db->data;
// ЕСЛИ СТРАНИЦЫ НЕ СУЩЕСТВУЕТ
if (!$id) {
header("HTTP/1.1 404 Not Found");
$component = "ОШИБКА 404! Данной страницы не существует";
}
$db->stop();

5. Создаём компонент вывода главной страницы

Главная страница у нас в базе данных хранится под псевдонимом «home», и пока по своей структуре не отличается от обычных страниц сайта - это просто статья. Тем не менее создадим для неё отдельный компонент - на перспективу, так сказать.

Содержимое компонента «home.php» в папке «com» почти совпадает с содержимым компонента обычной страницы, за исключением строки запроса к базе и названия компонента. Строка запроса теперь выглядит так:

$query = "SELECT * FROM wx_pages WHERE page_alias="home" LIMIT 1";

6. Создаём шаблон дизайна всего сайта

В корне сайта создаём файл template.php. По сути это обычный макет web-дизайна в формате HTML+CSS, только с PHP переменными в нужных местах. Между тегами title вставочка , в центральной колонке сайта вставочка и так по всему шаблону расставляем нужные переменные, которые объявлены в компонентах.

В корневой папке также должны быть папки «css» и «images» для элементов дизайна. В файле /css/style.css - можно настроить стили по своему усмотрению.

7. Чистые ссылки и файл.htaccess

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

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f

# ЗАПРЕЩЁННЫЕ ФАЙЛЫ
RewriteRule .htaccess - [F]
RewriteRule template.php - [F]

# ПРАВИЛА mod_rewrite
RewriteRule page/(+)([\/]{0,1})\.htm$ index.php?option=page&alias=$1 [L]

В будущем мы будем дописывать правила для компонентов поиска, каталога, блога статей и т.д. Смысл один: преобразовать ссылки вида «mysite.com/index.php?option=pages&alias=about » в ссылку вида «mysite.com/pages/about.htm » - смотрится довольно красиво. Старайтесь в разработке избегать массива $_GET в целях безопасности и не надеяться на него. Целесообразно хранить в нём только параметры для главного контроллера (переменная $option) и для компонента (переменная $alias).

Также в каждой папке сайта «на всякий случай» создайте пустой файл index.html - это нужно для того, чтобы при обращении к каталогу через адресную строку ничего не отображалось.

Теги: php, mysql, движок сайта, контроллер, создание сайта, mvc

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

Внешний вид рабочей области программы – таблица. А реляционная база данных структурирует информацию в строки и столбцы. Несмотря на то что стандартный пакет MS Office имеет отдельное приложение для создания и ведения баз данных – Microsoft Access, пользователи активно используют Microsoft Excel для этих же целей. Ведь возможности программы позволяют: сортировать; форматировать; фильтровать; редактировать; систематизировать и структурировать информацию.

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

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

База данных – набор данных, распределенных по строкам и столбцам для удобного поиска, систематизации и редактирования. Как сделать базу данных в Excel?

Вся информация в базе данных содержится в записях и полях.

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

Поле – столбец в БД, содержащий однотипные данные обо всех объектах.

Записи и поля БД соответствуют строкам и столбцам стандартной таблицы Microsoft Excel.

Если Вы умеете делать простые таблицы, то создать БД не составит труда.

Создание базы данных в Excel: пошаговая инструкция

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

Как создать базу данных клиентов в Excel:

Основная работа – внесение информации в БД – выполнена. Чтобы этой информацией было удобно пользоваться, необходимо выделить нужное, отфильтровать, отсортировать данные.

Как вести базу клиентов в Excel

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

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

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

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

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

В программе Excel чаще всего применяются 2 фильтра:

Автофильтр;
фильтр по выделенному диапазону.

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

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

Если в БД содержится финансовая информация, можно найти сумму по разным параметрам:

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

Порядок работы с финансовой информацией в БД:

Инструменты на вкладке «Данные» позволяют сегментировать БД. Сгруппировать информацию с точки зрения актуальности для целей фирмы. Выделение групп покупателей услуг и товаров поможет маркетинговому продвижению продукта.

Готовые образцы шаблонов для ведения клиентской базы по сегментам.