|
|
|
SergeBS |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 11 Всего: 22 |
Локальные, сетевые, серверные базы данных.
Или как бороться с базами данных цивилизованными методами. Disclaimer aka отмазка. Я не собираюсь открывать новых истин, не буду учить работать с базами данных. Я просто объясню, что и почему нужно знать, чтобы не наступать на грабли и не нагадить если не преемнику, то хотя бы себе... При этом я не собираюсь ничего никому доказывать. Кто знает – тот сразу согласится, а кто не знает – согласится когда узнает что такое нормальные формы, зачем нужен сервер, и что за язык такой SQL - про него куча народу знает, а исходников не видать, и не дают никто, жлобы . SergeBS Базы данных вообще. Итак, начнем с грустного. «В базе надо хранить то, се, … надо было еще вчера. Не сделаю - завтра уволят. Сами мы деревенские, книжных магазинов нету. Подскажите…» Или «Мне нужно сделать приложение с базой данных…ПАМАГИТЕ!!!». Не скажу, что тысячи (не считал), но уж сотни тем похожего содержания я видел. Самое прискорбное, что их авторы либо не догадываются о сложности задачи (это еще как-то простимо – ну не знает, совсем ничего не знает), либо просто хотят, чтобы их задачу «на халяву» решили (а за это надлежит канделябром…). В любом случае ответ на подобные послания: RTFM (Read The Fundamental/Following/Fucked/… Manuals). Это если кратко. А вот подробнее, но все равно кратко я нигде не нашел. Попытаюсь это дело исправить. Базы всякие нужны, базы всякие важны… Не надо мешать в одну кучу три большие разницы, а именно локальные, сетевые и серверные базы данных. Их различить очень легко, но почему-то все время путают. Итак «на пальцах» разница: Локальная база: на компьютере юзера расположено все – и программа и данные. Соответственно накрылся диск у юзера – данных больше нет (копию программы найти не проблема, как правило). Все ресурсы определяются возможностями конкретного компьютера. Сетевая база: юзер по-прежнему один! Еще раз повторю: ОДИН! Только чтобы не бояться результатов команды format c: и прочих пакостей, возможных с юзерскими руками и железом, база данных находится на файловом (сетевом) сервере, у которого есть средства резервного копирования, более надежное железо и т.п. Т.е в результате полная потеря данных невозможна – всегда есть копия n-дневной давности (у особо ленивых админов примерно месячной J ). НО! Этот сервер – штука пассивная, которая позволяет делать с данными что угодно и всего лишь обещает, что от ненадежности аппаратуры данные как-то защищены. А вот от любителей, например, одновременно в 3-х копиях программы редактировать одну и ту же таблицу, а потом удивляться – «а где же новые 50 записей» – нет. И еще стоит помнить про то, что раз работа идет по сети, то и скорость передачи данных соответственная. И что у файл-сервера дисковая система тоже имеет ограниченную скорость. А у юзера – процессор не обязательно шустрый и памяти не обязательно больше 64 Мб. Серверная база: я так для краткости обозвал. На самом деле это называется система «клиент-сервер». Только в этом случае юзеров может быть больше одного. Есть еще и усугубление этой технологии, называемое в просторечии многозвенкой, но кто про многозвенку знает, тот мой опус читать не будет. Так вот, главное в этой технологии: есть специально выделенный компьютер, на котором работает специальная программа (приложение, сервис, служба – обозвать можно как угодно). И только эта программа работает с данными непосредственно, а все юзеры для работы обращаются к ней. Это и есть сервер базы данных. Ограничения: сетевой траффик, процессор, память и дисковая система сервера. Плюс еще юзеров толпа, а не всего один. Как раз многозвенка и предназначена для борьбы с этими ограничениями, а еще кластеры. Но о них – потом (если получится). Главное: только в этом случае можно получить надежную работу нескольких юзеров. Где несколько – от 2 до, например, 200. Или 2000. От задачи зависит. Независимо от технологии доступа существует еще структура хранения данных. Если она неправильная, то ничего хорошего ждать нечего. И тут главное: не путать умение сделать таблицу с умением сделать правильную структуру. Таблицы и их связи – это те кирпичики, из которых и строят структуры. Поэтому правильное проектирование базы данных (БД) – задача «немного» сложнее, чем сделать несколько таблиц и показать их в нескольких окошках. Итого, чтобы получить правильный результат, надо организовать правильный доступ к данным и создать правильную структуру данных. А теперь подробнее. Когда формы определяют содержание… Давно назад, когда компьютеры, даже самые маленькие, по размерам превосходили документацию на их софт, после решения задачи как что-то на них посчитать начали решать задачу как что-то в них хранить и искать. И почти решили… Если коротко: от просто таблиц перешли к инвертированным спискам, древовидным и сетевым базам, от них – к реляционным и постреляционным. А сейчас уже вовсю идет соревнование в объектно-ориентированных технологиях, т.е. когда предмет разработки - не только данные, но и процессы их обработки несколькими взаимосвязанными объектами (например пассажир-кассир-пилот-авиадиспетчер…). И все это держится в первую очередь на такой простой, если разобраться, вещи как нормальные формы (НФ). Которые всего-навсего набор правил: что нужно сделать, чтобы хранение и манипулирование данными было эффективно. Не зная, что такое НФ, можно, конечно, что-то сделать. И это что-то даже будет работать, совсем даже не исключено. Только вот чем дальше, тем больше времени и сил будет уходить на внесение любых, даже чисто косметических изменений этого «что-то». И в конце концов это «что-то», испортив кучу нервов окружающим, будет выкинуто. Или после долгих и мучительных изобретений круглого колеса приведено в соответствие с этими самыми нормальными формами. Вывод: если человек не знает, что такое НФ, то проектировать базы данных (БД) он просто не имеет права. И крики о том, что «иначе уволят», «нужно срочно» и т.п. - не оправдание. Поскольку все равно уволят, а быстрее все равно не получится. Ну ладно, не будем о грустном. Лучше почитаем Дейта «Введение в системы баз данных», или Райордан «Основы реляционных баз данных», или еще кого-нибудь, например статью Федорова и Елмановой «Введение в базы данных» (для разминки), или лекции «Основы современных баз данных» Кириллова и Громова. Главное чтобы на обложке книжки или внутри было что-то похожее на эти самые магические «СУБД», «нормальная форма» и т.д.. Дейт вообще-то полезнее, поскольку уже давно записан в классики. Но кто-то любит коньяк, а кто-то «горилку з перцем». Главное, что результат прост: либо применяем НФ и все (возможно) работает быстро и правильно, либо не применяем – и все тормозит и разваливается (гарантированно, но не обязательно быстро). Я назвал его сервер… Свершилось! С помощью лома и топора (а кто похитрей – с помощью ErWin или BpWin) структура базы данных разработана. И даже написана программа, которая что-то из нее показывает. И даже редактировать записи можно! Но начальство уже не хочет просто персональных баз данных. Им подавай общую на всех, и чтобы каждый видел только то, что ему положено. И тут легко наступить на грабли: положить БД в виде толпы dbf-ок, или одного mdb/gdb-файла куда-нибудь, где всем видно. А потом приляпать каждой таблице хитрое поле, чтобы каждую запись можно было редактировать кому-то одному. А можно и не приляпывать – само все образуется. Будем средствами программы блокировать от всех прочих запись, пока кто-то один в нее пишет. FoxPro например это умеет. Если так поступить, то сразу проблем может и не возникнет. Проблемы будут потом, причем гораздо раньше, чем в случае с НФ, и гораздо тяжелее. База данных будет периодически терять записи, искажать их, а может и вообще полностью рухнуть. Хотя вовсе не обязательно, что это произойдет в первую же неделю эксплуатации. Процесс носит чисто вероятностный характер. Например, один юзер прочитал поле блокировки и получил «свободно». Он желает записать «занято». Пока он собирался записать «занято», другой юзер тоже прочел это поле и получил тоже – «свободно», а потом они по очереди записали «занято» и по очереди записали свои данные. Причем для разных полей очередь у них была разная. Вероятность этого мала, но не 0. Не нравится? Ладно, вот еще вариант: некий клиент многопользовательской системы: - перешел на запись и получил значение поля «свободно»; - выставил поле в «занято»(начал запись редактировать); - нажал на “reset” (ушел на перекур/на обед/запустил Quake); Результат: запись заблокирована и всеобщей перезагрузкой это не лечится. В локальных БД похожим образом может быть заблокирована или разрушена вся таблица - по заголовку. При сколько-нибудь развитой фантазии и «злом умысле» количество пунктов, приводящих «в морг», легко увеличивается, ибо "ненадежность аппаратуры оправдывается тем, что человек еще ненадежнее". Ну и что теперь делать? Ничего особенного. Просто обратить внимание на то, что ВСЕ проблемы вытекают из того, что приложение (клиент) командует блокировкой и вводом данных. И в результате имеем «организованную толпу», которая мешает и себе и друг другу. В этом случае правильное решение задачи только одно: сервер. Но не тот сервер, у которого диск всем по сети виден, а сервер базы данных. Например, что-либо из Oracle, MS SQL, InterBase, MySQL, Advantage DS, DB/2 … Эта технология и называется «клиент-сервер». Что конкретно из серверов выбрать – зависит от задачи и личных пристрастий. В наше время всяких серверов развелось почти столько же, сколько языков программирования. А может и больше. Навскидку цифры близкие. Главное не впасть в крайность. Простейший пример такой крайности: установить Oracle и на нем вести базу данных заводской художественной библиотеки – кто какую книгу взял. Это будет как на 10-тонной фуре везти 5 кило песку. Если конечно у вас не 1.000.000 работников и не 1.000.000 книг . Такой завод тоже крайность. И даже для такого завода Oracle применять не обязательно. Но уже можно. Сервер, сервер, ты могуч… Уфф! Оказывается и начальники могут иногда что-то понять! Купили-таки XP ProLiant, хоть что-то, а к нему в придачу APC 1400. Сейчас поставим на него Win2000 server, MS SQL (Oracle) взгромоздим, чтоб круть была немеряная и порулим дальше. И вот тут уже наступает очередь для других граблей. Условно их можно назвать так: «на сервере по-dbf-ному». Тут имеет смысл прочитать Переходим на клиент-сервер (советы). Я правда не разделяю восторгов автора по поводу ADO и неприязни к ODBC. Хотя бы по той причине, что ODBC – открытый стандарт, драйверы писали и пишут все кому не лень, и скорость работы зависит от криворукости драйверописателя и его хитрости. Поэтому мне кажется, что, например, ODBC драйверы от Micro$oft быстрее всего будут работать с Micro$oft же поделиями, а с прочими – «для галочки». Но на эту тему – потом (если получится). Вернемся к нашим баранам: «на сервере по-dbf-ному». Простейший пример: есть SQL-сервер. Надо для отчета в какой-то таблице (например Payment) узнать сумму по столбцу, ну назовем его MySales. Первый способ - подход «по-dbf-ному»: переходим в начало таблицы, а дальше в какую-то переменную добавляем содержимое столбца MySales, сдвигаемся на запись вниз и опять добавляем … и так до конца таблицы. Это будет медленно и не всегда возможно. Правильный подход - поискав в голове умную мысль, соображаем: SQL = Structured Query Language (структурированный язык запросов). Заглянув в документацию на SQL-сервер, заставляем его с помощью SQL вычислить нужную сумму и передать ее нам. Что-нибудь вида SELECT SUM(MySales) FROM Payment И вот тут мы получим как говорят в Одессе «две большие разницы». В первом случае нужно через сеть перетащить по очереди, по каждой записи, всю таблицу на машину-клиент и там просуммировать один столбец. А если этих столбцов десятка 3, да еще половина – текстовые? А нужен-то всего один. В этом и заключены медленность и не всегда возможность. Во втором случае серверу на том пресловутом языке SQL, исходников программ на котором почти не дают, скомандовано: «посчитать сумму столбца MySales таблицы Payment». Главные тут 2 пункта: 1. Вся таблица по сети не передается, передаются команда и результат ее выполнения. 2. Считает результат не клиентская машина, которая может быть сколь угодно слабой, а сервер, который как аппарат по традиции имеет более мощное и надежное «железо». К тому же считает не абы как, а с помощью специальной программы (SQL-сервера), которая для таких задач и задумана была. Если добавить, что SQL позволяет не только получение сумм, но и много другого, то вывод прост: работать по технологии клиент-сервер и не знать хотя бы основ SQL – недопустимо. А знать придется именно тот диалект SQL, который реализует сервер. Иначе при супер-сервере и супер-локальной сети гарантируется скорость работы на уровне ENIAC (компьютер 1946 г. выпуска) – все будет уходить на перекачивание мегабайт данных между сервером и клиентами. А потому для начала, в качестве легкого, почти как дамский роман, но менее объемного чтива берем Грубера(Грабера), т.е. GRUBERа «Понимание SQL». Или лекции Кириллова и Громова – у них и про построение БД и про SQL есть. Кто хочет MS SQL – читает Райордан по 2-му разу. Востриков и Ковязин - «Мир Интербейз». И т.п. Найти в электронном виде на русском языке книжку про интересующий сервер – не проблема. Надо лишь понять что это надо искать. Заодно становится ясным, почему исходников на SQL почти нет – базы-то у всех разные, а считать интегралы или рисовать красивые картинки на SQL как-то не принято . В результате имеем - чтобы несколько юзеров могли успешно работать с данными, нужно: 1. При проектировании базы данных использовать нормальные формы. Это впрочем для любой БД нужно и научиться этому несложно. Сложнее заставить себя потратить время на это обучение. Но только в самый первый раз . 2. Выбрать по задаче и личным симпатиям сервер. Тут посложнее – ассортимент большой. Все серверы перепробовать не получится. Но кое-какие ограничения на выбор можно найти. 3. Выбрать механизм доступа к этому серверу. Тут можно просто взять несколько разных и попробовать. Могут тоже найтись ограничения. 4. На чем клиентское приложение делать – каждый сам для себя решит, здесь выбор очевиден . Первый пункт – просто вопрос добросовестности, по большому счету. По 2 и 3 пункту когда-нибудь попробую продолжить. |
|||
|
||||
EvilsInterrupt |
|
|||
Executables research Профиль Группа: Завсегдатай Сообщений: 1019 Регистрация: 14.7.2007 Где: Железнодорожный, МО, Россия Репутация: нет Всего: 9 |
SergeBS,
Несмотря на то что статья уже давно написана, прочитал только сегодня. Рекомендации: 1. Добавить "Список рекомендуемой литературы" и в нем перечислить все что рекомендуешь 2. Добавить "Список рекомендуемых ресурсов" и внем я бы добавил веб-ресурс sql-ex.ru 3. В начале статьи добавил бы : "Для кого написана статья ?" и обозначить предполагаемого читателя 4. Добавить "Список хороших SQL-запросов" и внем бы архив с запросами с указанием СУБД, с пояснением почему же этот запрос хорош ? |
|||
|
||||
pseud |
|
|||
Экспёрт Тыдыщ Профиль Группа: Завсегдатай Сообщений: 1175 Регистрация: 18.5.2007 Где: Минск, Беларусь Репутация: 16 Всего: 40 |
5. поформатировать статейку -------------------- Испытание чужого терпения можно считать успешным, если оно лопнуло... |
|||
|
||||
EvilDog |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 4.12.2008 Репутация: нет Всего: нет |
Читать не стал, так как ничего нового не почерпнул для себя, давно работаю с базами данных, в основном создаю клиент-серверные приложения, СУБД - тонкий клиент....
|
|||
|
||||
flomaster |
|
|||
Новичок Профиль Группа: Участник Сообщений: 37 Регистрация: 28.12.2007 Где: СПб Репутация: нет Всего: нет |
Ссылка "Переходим на клиент-сервер (советы)." (http://forum.vingrad.ru/topic-35805.html) не открывается:
"Вы не имеете прав чтения этого форума. Если данный форум защищён паролем, то Вы должны авторизоваться в этом форуме, зайдя в него с главной страницы форума." |
|||
|
||||
Zerstroer |
|
|||
Опытный Профиль Группа: Участник Сообщений: 285 Регистрация: 8.8.2007 Где: Алма-Ата Репутация: нет Всего: 3 |
Хорошая статья. Просто написана. Совсем новичку основные понятия будут очень полезны. Было бы хорошо, таким простым языком добавить чуточку очень важной конкретики - например, описать те же самые нормальные формы - в 98% в книгах при их объяснении совершенно непонятные вещи пишут.
-------------------- In silico |
|||
|
||||
khasan12 |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 8.7.2013 Репутация: нет Всего: нет |
много воды
|
|||
|
||||
Akella |
|
|||
Творец Профиль Группа: Модератор Сообщений: 18485 Регистрация: 14.5.2003 Где: Корусант Репутация: 29 Всего: 329 |
khasan12, напиши без воды
|
|||
|
||||
Правила форума "Delphi: Базы данных и репортинг" | |
|
Запрещено: 1. Публиковать ссылки на вскрытые компоненты 2. Обсуждать взлом компонентов и делиться вскрытыми компонентами Обязательно указание: 1. Базы данных (Paradox, Oracle и т.п.) 2. Способа доступа (ADO, BDE и т.д.)
FAQ раздела лежит здесь! Если Вам помогли и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, Vit, Петрович. |
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Delphi: Базы данных и репортинг | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |