?

Log in

No account? Create an account
hor
DSSh
Странная тема... 
1-ноя-2010 08:24 pm
hor
Полез я тут познать неизведанное для себя, а именно Базы Данных. Понял, что литература по этой трогательной теме весьма странная, ибо начинается она не с проблемы, не с задачи, а хрензнаетсчего. Поэтому мне интересно: есть ли нормальная литература по теме? Если да, то буду признателен за ссылку.

Как я себе вижу задачку создания БД.
1) есть некоторые множества: числовые, символьные, состоящие из макро-объектов и т.п.
2) есть запись, суть элемент декартова произведения этих множеств
3) множество таких записей образуют то, что называется БД
такое описание вполне наглядно, позволяет произвольно расширять как сами множества, так и их количество, не внося хаос в уже сделанные записи. Как я понимаю, такая модель БД называется "Реляционная база данных", хотя и не понимаю зачем ее так назвали. Статья в википедии (с отростками) звучит как дефективный перевод с элементами бреда: "Строгое изложение предполагает использование строгих математических терминов отношение, домен, атрибут, кортеж, а не смутных и нестрогих понятий таблица, поле, столбец, колонка, запись, строка." - ага, вся теория матриц - коту под хвост, ибо пользует смутные понятия "таблица, столбец, строка"...

Поправьте, кто знает, в чём я не прав.

Проблемы (задачи) обработки и поддержки БД:

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

Проблемы изменения записей:
1) дополнение
2) удаление
3) изменение базовых множеств
4) изменение числа базовых множеств
это уже программно-аппаратные проблемы, например, навскидку мне непонятно, как решить массовое обращение к БД с целью ея изменения. Тупо распараллелить процессы за счет памяти (буфера)?

Вот.. если кто-то что-то может сказать по написанному - милости прошу. Фразы: "ты козел и нихрена не понимаешь" допустимы, если будет пояснение, что именно я нихрена не понимаю.
Comments 
1-ноя-2010 09:13 pm
Ты козел и нихрена не понимаешь ;-).

Производительность производительностью, но представь себе, что обращения к базе следуют с частотой порядка миллионов штук в секунду. Не такая уж нереальная ситуация для какой-нибудь соцсети среднего размера. Поэтому оптимизация вполне себе актуальна.
2-ноя-2010 04:07 am
Ага, точно. Впрочем "массовое обращение к БД с целью ея изменения" - задача покрывающая просто обращение с целью "почитать". Но, с другой стороны, читают в разы (на порядки) чаще, чем меняют... дя, то есть задачки логично разнести.
2-ноя-2010 03:50 pm
Ну в общем любую "Базу" можно разделить на две части.

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

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

От того насколько грамотно составлена первая часть "Базы" зависит простота работы с данными этой "Базы".

Вторых частей "Базы" может быть несколько. Каждая из которых будет направлена на свои разделы данных, хранящихся в первой части.

Serge37
3-ноя-2010 08:26 am
Ага, спасибо. Вот это понятно.
А как можно накосячить с индексацией данных? Казалось бы, есть данное, поставь ему следующий номер (индекс) и внеси в список.
Вот мне еще подсказали, что возможны данные зависящие от данных (формулы какие и т.п.), вот там, наверное, можно много накосячить.
3-ноя-2010 12:12 pm
Anonymous
Нет, ты немного не понял. В твоем понимании накосячить с индексами действительно сложно. Тем более, что чаще всего тип индексного поля – счетчик.
Имелось в виду немного другое.
Вот по ссылке http://s004.radikal.ru/i206/1011/45/875ea80276ef.jpg две таблицы, суть которых одинакова – данные по сотрудникам. Но в левой таблице будет очень сложно искать, если например, потребуется сделать выборку по сотрудникам, родившимся в определенном году или проживающим в определенном городе (области, улице и т.д.). Придется подключать символьные функции, которые из адреса «г. Москва, Красная площадь, дом1» будут выбирать названия улиц, городов и областей. Тоже самое и с датой рождения.
Совсем другое дело в правой таблице. В ней без применения дополнительных функций можно делать выборки по годам, месяцам, областям и т.д.
Но и это еще не все. Исключить ошибки при внесении данных (человеческий фактор) полностью не возможно. Допустим оператор, заносивший должность некого Иванова И.И. вместо должность инженер, записал должность инжИнер. Тогда при поиске сотрудников с должностью инженер Иванов И.И. не найдется. Тоже самое и с адресом, подразделением.
А вот при таком http://s008.radikal.ru/i306/1011/80/ad3971777adb.jpg построении базы такие ошибки будут исключены. Надеюсь понятно нарисовал.

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

Serge37
3-ноя-2010 02:27 pm
О! Класс. Спасибо, Сергей, то, что надо. На деле, как я понимаю, во второй картинке в записи "сотрудник" могут стоять только индексы соответствующих массивов данных.
Итак, кроме понятных проблем "сортировка и поиск", возникает некая "субъективная" проблема - уровень детализации данных, или выбираемые данные для базы...
8-ноя-2010 08:12 am
Anonymous
Да, именно так и поступают. Во первых при этом повышается скорость выборок. По индексу SQL сервер из любой большой базы (несколько десятков Гбайт) практически моментально выведет искомую запись в таблице. Во вторых, экономится место. Для индекса обычно используется 4 байта, а вот для хранения ФИО сотрудника, например, Новоблаговещенская Ю.П. - 23 байта. И если каждый раз в таблицах, где фигурирует сотрудник использовать индекс из таблицы Сотрудники, то экономия получается значительной. Кроме того, при необходимости получить более подробные данные по этому сотруднику, по индексу из таблицы Сотрудники это не составит труда.
Запросы к Базе данных обычно выполняются с использованием языка SQL запросов. Основных запросов всего четыре:
SELECT – выбрать строки из таблиц;
INSERT – добавить строки в таблицу;
UPDATE – изменить строки в таблице;
DELETE – удалить строки в таблице;
Формат запросов можно посмотреть, например, по ссылке http://www.woweb.ru/publ/45-1-0-335
Естественно только ими не ограничивается язык SQL, но для того, чтобы понять механизм работы с Базой их достаточно. Выполнение этих запросов максимально оптимизировано программным обеспечением SQL сервера. Конечному пользователю передаются только результаты выполнения этих запросов, а не весь массив таблиц. Кроме того, SQL сервер следит за целостностью данных, т.е. два пользователя одновременно не смогут изменить одну и ту же запись в таблице (UPDATE), но в тоже время прочитать эту запись (SELECT) – легко.

"Итак, кроме понятных проблем "сортировка и поиск", возникает некая "субъективная" проблема - уровень детализации данных, или выбираемые данные для базы... "
Вот здесь не совсем понял, что имеется ввиду.
8-ноя-2010 02:48 pm
Ага, понятно.

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

Вот выбор этой детализации - субъективное действо. Как-то так.
This page was loaded апр 27 2018, 6:54 am GMT.