Модераторы: Rodman
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Локальные, сетевые, серверные базы данных. как бороться с базами данных 
:(
    Опции темы
SergeBS
Дата 30.5.2006, 09:52 (ссылка) |   (голосов:3) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1111
Регистрация: 10.6.2005
Где: Владимир

Репутация: 11
Всего: 22



Локальные, сетевые, серверные базы данных.
Или как бороться с базами данных цивилизованными методами.

Disclaimer aka отмазка.
Я не собираюсь открывать новых истин, не буду учить работать с базами данных. Я просто объясню, что и почему нужно знать, чтобы не наступать на грабли и не нагадить если не преемнику, то хотя бы себе... При этом я не собираюсь ничего никому доказывать. Кто знает – тот сразу согласится, а кто не знает – согласится когда узнает что такое нормальные формы, зачем нужен сервер, и что за язык такой SQL - про него куча народу знает, а исходников не видать, и не дают никто, жлобы smile.
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 книг smile. Такой завод тоже крайность. И даже для такого завода 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 как-то не принято  smile . 

В результате имеем - чтобы несколько юзеров могли успешно работать с данными, нужно:
1.    При проектировании базы данных использовать нормальные формы. Это впрочем для любой БД нужно и научиться этому несложно. Сложнее заставить себя потратить время на это обучение. Но только в самый первый раз smile.
2.    Выбрать по задаче и личным симпатиям сервер. Тут посложнее – ассортимент большой. Все серверы перепробовать не получится. Но кое-какие ограничения на выбор можно найти.
3.    Выбрать механизм доступа к этому серверу. Тут можно просто взять несколько разных и попробовать. Могут тоже найтись ограничения.
4.          На чем клиентское приложение делать – каждый сам для себя решит, здесь выбор очевиден smile.
Первый пункт – просто вопрос добросовестности, по большому счету. По 2 и 3 пункту когда-нибудь попробую продолжить.
 
PM MAIL   Вверх
EvilsInterrupt
Дата 25.2.2008, 22:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Executables research
***


Профиль
Группа: Завсегдатай
Сообщений: 1019
Регистрация: 14.7.2007
Где: Железнодорожный, МО, Россия

Репутация: нет
Всего: 9



SergeBS
Несмотря на то что статья уже давно написана, прочитал только сегодня.

Рекомендации:
1. Добавить "Список рекомендуемой литературы" и в нем перечислить все что рекомендуешь
2. Добавить "Список рекомендуемых ресурсов" и внем я бы добавил веб-ресурс sql-ex.ru
3. В начале статьи добавил бы : "Для кого написана статья ?" и обозначить предполагаемого читателя
4. Добавить "Список хороших SQL-запросов" и внем бы архив с запросами с указанием СУБД, с пояснением почему же этот запрос хорош ?
PM MAIL WWW ICQ Jabber   Вверх
pseud
Дата 26.8.2008, 16:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Экспёрт Тыдыщ
***


Профиль
Группа: Завсегдатай
Сообщений: 1175
Регистрация: 18.5.2007
Где: Минск, Беларусь

Репутация: 16
Всего: 40



Цитата(EvilsInterrupt @  25.2.2008,  22:01 Найти цитируемый пост)

SergeBS, 
Несмотря на то что статья уже давно написана, прочитал только сегодня.
Рекомендации:


5. поформатировать статейку



--------------------
Испытание чужого терпения можно считать успешным, если оно лопнуло...
PM MAIL   Вверх
EvilDog
Дата 4.12.2008, 13:36 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 1
Регистрация: 4.12.2008

Репутация: нет
Всего: нет



Читать не стал, так как ничего нового не почерпнул для себя, давно работаю с базами данных, в основном создаю клиент-серверные приложения, СУБД - тонкий клиент....
PM MAIL   Вверх
flomaster
  Дата 4.9.2009, 23:00 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 37
Регистрация: 28.12.2007
Где: СПб

Репутация: нет
Всего: нет



Ссылка  "Переходим на клиент-сервер (советы)." (http://forum.vingrad.ru/topic-35805.html) не открывается:

"Вы не имеете прав чтения этого форума. Если данный форум защищён паролем, то Вы должны авторизоваться в этом форуме, зайдя в него с главной страницы форума."



PM MAIL   Вверх
Zerstroer
Дата 24.11.2010, 23:29 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 285
Регистрация: 8.8.2007
Где: Алма-Ата

Репутация: нет
Всего: 3



Хорошая статья. Просто написана. Совсем новичку основные понятия будут очень полезны. Было бы хорошо, таким простым языком добавить чуточку очень важной конкретики - например, описать те же самые нормальные формы - в 98% в книгах при их объяснении совершенно непонятные вещи пишут. 


--------------------
Надо больше работать и больше спать! (Иван Полторацкий (с))
PM MAIL ICQ   Вверх
khasan12
Дата 14.7.2013, 22:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 1
Регистрация: 8.7.2013

Репутация: нет
Всего: нет



много воды
PM MAIL   Вверх
Akella
Дата 2.10.2013, 09:10 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Творец
****


Профиль
Группа: Модератор
Сообщений: 18470
Регистрация: 14.5.2003
Где: Корусант

Репутация: 29
Всего: 329



khasan12, напиши без воды smile 
PM MAIL   Вверх
Google
  Дата 25.9.2017, 21:54 (ссылка)  





  Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Delphi: Базы данных и репортинг"
Vit
Петрович

Запрещено:

1. Публиковать ссылки на вскрытые компоненты

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


Обязательно указание:

1. Базы данных (Paradox, Oracle и т.п.)

2. Способа доступа (ADO, BDE и т.д.)


  • Литературу по Дельфи обсуждаем здесь
  • Действия модераторов можно обсудить здесь
  • С просьбами о написании курсовой, реферата и т.п. обращаться сюда
  • Вопросы по реализации алгоритмов рассматриваются здесь
  • 90% ответов на свои вопросы можно найти в DRKB (Delphi Russian Knowledge Base) - крупнейшем в рунете сборнике материалов по Дельфи
  • Вопросы по SQL и вопросы по базам данных не связанные с Дельфи задавать здесь

FAQ раздела лежит здесь!


Если Вам помогли и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, Vit, Петрович.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Delphi: Базы данных и репортинг | Следующая тема »


 




[ Время генерации скрипта: 0.0943 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.