Реляционные базы данных - должно быть более правильно?

Ответ 1

Я буду предлагать список областей, которые вы можете рассмотреть как аспекты программирования с базами данных. Я бы не стал утверждать, что вам нужно быть экспертом во всех их или даже большинстве из них, чтобы иметь возможность программировать с использованием СУБД и даже не программировать СУБД. Тем не менее, это все темы, которые имеют некоторое значение в некоторые моменты - в определенном порядке:

• Дизайн языка запросов
• Оптимизация запросов
• Переписывание запросов
• Типы данных
• Организация хранения
• Управление транзакциями
• Протоколы связи
• Шифрование
• Аутентификация и идентификация
• Схема схемы
• Репликация
• Резервное копирование и восстановление
• Двухфазные фиксации
• Оптимистичный concurrency контроль
• Блокировка и пессимистическое управление concurrency
• Разрешение
• Контроль доступа на основе этикеток
• Теория множеств
• Теория отношений
• Распределенный запрос
• Логическая логика
• Пользовательские типы и функции
• Управление каталогом
• Управление буфером
• Сортировка
• Интернационализация (I18N), Локализация (L10N), Глобализация (G11N)
• Кванторы
• Аудиторская
• Триггеры
• Сохраненные процедуры

Я не претендую на полноту или минимальность.

Ответ 2

Стандартный текст в поле "Введение в системы баз данных", C. J. Date.

У меня есть опыт работы на 20 лет; Я прочитал его, подумал, что это отлично, и я написал реляционную базу данных из-за этого (правильный, а не этот SQL-малярий!).

Ответ 3

Целая другая область - это моделирование размеров и хранилище данных.

Я много лет работал с реляционным моделированием, а затем прочитал The Data Warehouse Toolkit и получил совершенно новое представление о том, как это сделать могут быть использованы.

Ответ 4

Получите больше грязи с CJ Date База данных по глубине: теория отношений для практиков, если его "Введение в системы баз данных" недостаточно для вас.

Ответ 5

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

http://database-programmer.blogspot.com/2008/09/comprehensive-table-of-contents.html

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

Другой - высокая масштабируемость...

http://highscalability.com/

Они попадают во все сферы БД.

Надеюсь, что это поможет.

Ответ 6

Я думаю, что set + реляционная алгебра - это то, о чем мало знают пользователи базы данных, но было бы полезно учиться. Когда вы цените логику, связанную с отображением одного отношения к другому, вы начинаете более четко понимать, почему такие вещи, как нормализация, хороши, почему NULL лучше избегать, если это возможно, и т.д. Вы также начинаете видеть недостатки в SQL по сравнению с более чистыми реляционными языками запросов, где функции налагают ограничения на парадигму из-за причин производительности и т.д.

Ответ 7

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

Ответ 8

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

Некоторая базовая алгебра отношений - полезное знание и тесно связана с теорией множеств.

Ответ 9

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

Полнотекстовый поиск и XML - это темы, которые, кажется, все больше появляются.

У меня нет опыта в этом, но я знаю, что DB2 (у которой есть пробная версия) имеет некоторые сумасшедшие новые функции)

Удачи: -)

Ответ 10

http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html

http://blogs.msdn.com/pathelland/archive/2007/07/23/normalization-is-for-sissies.aspx

http://www.25hoursaday.com/weblog/2007/08/03/WhenNotToNormalizeYourSQLDatabase.aspx

http://itc.conversationsnetwork.org/shows/detail571.html

http://www.scribd.com/doc/2592098/DVPmysqlucFederation-at-Flickr-Doing-Billions-of-Queries-Per-Day

http://highscalability.com/flickr-architecture

http://highscalability.com/ebay-architecture

http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

http://blog.maxindelicato.com/2008/12/scalability-strategies-primer-database-sharding.html

http://blog.maxindelicato.com/2008/12/the-ihsdf-theorem-a-proposed-theorem-for-the-tradeoffs-in-horizontally-scalable-systems.html

http://www.iamcal.com/talks/

http://natishalom.typepad.com/nati_shaloms_blog/2009/04/writing-your-own-scalable-twitter.html

http://www.mysqlperformanceblog.com/

http://www.cecs.uci.edu/~papers/ipdps07/pdfs/SMTPS-201-paper-1.pdf

http://video.google.com/videoplay?docid=7278544055668715642

http://www.niallkennedy.com/blog/uploads/flickr_php.pdf

Ответ 11

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

Так что сделайте вид, что вы, как и я, должны иметь дело с несколькими базами данных, а не с большими (по 100 ГБ каждый), и у вас много клиентов со множеством различных потребностей, которые заставляют вас разрабатывать множество настраиваемых решений, например, создавать пользовательские отчеты или экспорта. Это делает вас скорее программистом, чем администратором баз данных. И вам нужна производительность, прежде чем производительность.

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

Ответ 12

Отказ от ответственности: не специалист по дизайну базы данных.

Некоторые проблемы производительности могут быть обработаны либо с помощью:

• денормализация вашей базы данных, поэтому для уменьшения количества таблиц для присоединения
• добавление индексов Фильтрация
• должна быть выполнена так, чтобы вы сначала удалили самую большую из несовпадающих данных, затем вы вишневы выбираете следующее условие для уменьшенного набора. Лучше перейти от 100 значений → 10, соответствующих первому условию → 1, соответствующего первому и второму условию, чем 100 значений → 80, соответствующее второму условию → 1, соответствующему первому и второму условию. Кажется тривиальным, но важно иметь в виду.

• divide et impera - девиз для масштабируемости. Если у вас есть что-то, что масштабируется нелинейным способом, скажем O (N ^ 2), имеет смысл держать N как можно ниже, и вы должны разбить свой набор данных на более мелкие наборы, если они независимы, и вы можете выработать разбиение. Примером этого является очертание, обычно используемое для хранения баз данных пользователей на крупных социальных сайтах. (NB: пример, я бы не реализовал его таким образом) Вместо того, чтобы иметь огромную базу данных со всеми пользователями, у них есть 26 серверов (по одной для каждой буквы алфавита), затем они помещают все псевдонимы с одинаковой первой буквой на том же сервере. Это имеет следующие преимущества:

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

Ответ 13

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

Стандартные методы (по меньшей мере, для иерархии) упоминались в этих сообщениях SO:

• Иерархия отчетов в таблицах Mutltiple
• Каков наиболее эффективный/элегантный способ разобрать плоскую таблицу в дерево?

edit: там также пространственная база данных приложения для использования ГИС, где у вас есть структуры данных и/или индексы на основе местоположений точек, используя R-деревья и тому подобное. Использование этих функций немного отличается от обычных функций не пространственной базы данных.

Ответ 14

На мой взгляд, есть три "трека" с навыками базы данных: разработчик, администратор баз данных и архитектор. С точки зрения развития, вы хотите сосредоточиться на разработке, понять архитектора и собрать как можно больше материалов DBA по мере необходимости.

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

Хранимые процедуры (не только, как их использовать, но когда и почему)
Виды (в том числе материализованные виды)
Триггеры (вставка, обновление, удаление, как и почему)
Курсоры (особенно влияние на производительность)
Ссылочная целостность
Сделки
Индексы
Добавление значений по умолчанию, ограничений и идентификаторов к таблицам
Комплексное использование группы и Функции особенно:
 - Обработка даты и времени
 - Обработка строк
 - Обработка нулей

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

Как разработчик, одно бронирование, на которое я бы посмотрел, - это Joe Celko SQL для Smarties. Множество SQL, чтобы делать то, что вы, возможно, никогда не думали о возможности делать в SQL.

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

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

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

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

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

В терминах ссылок это зависит от платформы - все это имеет тенденцию быть специфичным для платформы. Но тогда для чего предназначен Google.

Я не подозреваю полностью, что вы хотите, но стоит знать, поскольку многие люди, которые считают, что они знают SQL, действительно действительно не...

Ответ 15

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

Ответ 16

Я бы посоветовал немного сузить область действия. выбрать сервер sql и стать экспертом в нем... например, получить mysql, узнать разницу между типами хранилищ, типами репликации и т.д. реализовать репликацию несколькими различными способами. получить большой набор данных и попытаться оптимизировать запросы. сделайте несколько опорных точек и оптимизируйте свои индексы для этого. исследовать стратегии резервного копирования. как повысить производительность репликации и резервных копий, когда у вас есть база данных 10gb, которая последовательно добавляет 100 000 транзакций каждый день. написать программное обеспечение для вставки записей и сценариев для выполнения репликации и резервного копирования.

трудно стать эффективным dba без реального опыта, когда вы пытаетесь охватить все серверы sql. просто сосредоточьтесь на одном... я бы предложил mysql или mssql, но независимо от того, что плавает ваша лодка.

-don

Ответ 17

Существует только один строгий метод концептуального моделирования схемы реляционной базы данных, о которой я знаю (и я потратил много времени на поиск). Он смутно назвал "Object-Role Modeling". Вот пара ссылок.

http://www.agilemodeling.com/artifacts/ormDiagram.htm

http://www.tdan.com/view-articles/5033

http://en.wikipedia.org/wiki/Object_role_modeling

http://en.wikipedia.org/wiki/NORMA

и здесь плагин для Visual Studio

Ответ 18

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

Параллель от LDAP заключается в том, что он является протоколом и этим не является определение того, что вы можете с ним сделать и как его реализовать, то же самое можно сказать и о SQL.

Итак, если вы хотите узнать больше о базах данных, вы на самом деле говорите, что хотите узнать больше о протоколе SQL и/или о том, как хранить и извлекать данные.

Вам может быть интересно узнать, что такое "B-Tree" и как оно используется. Еще одна вещь, заслуживающая внимания - EAV (Entity-Attribute-Value) и почему схема так важна для нее.

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

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

Ответ 19

Вы можете начать с чтения одной из (почти недавних) обзоров, посвященных основам и тенденциям в Базах данных: Анатомия баз данных