2009-04-15 3 views
15

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

Мой уровень знаний, когда дело доходит до баз данных, однако (я бы догадался) довольно простой - я могу корректно моделировать отношения данных с диаграммами ER, таблицами соединений, обрабатывать много-ко-многим, один-ко-многим и т. Д. И т. Д. Я знаю, когда речь заходит о программировании в целом, и я полагаю, что знание моей базы данных - это знание основ объектно-ориентированного программирования, то есть, как моделировать класс автомобиля, унаследованный от класса транспортного средства, содержащий объекты колес и т. Д. ,

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

Все, что я могу сейчас сделать, это, вероятно, моя база данных фильмов в конце моего личного сайта, которая, вероятно, рухнет, если бы я был Amazon и должен был хранить миллионы фильмов. Значит, есть вопрос о масштабируемости? Я уверен, что в дизайне базы данных есть довольно «стандартный» массив предметов/концепций, которые вы просто должны понимать и иметь возможность применять в реальной жизни, если вы собираетесь работать с базами данных на профессиональном уровне.

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

Заранее благодарен!

+0

«Смотрите, что я клоню» - не полностью. Это проблема «масштабируемости», которая является равным компонентом приложения, операционной системы и базы данных. «промышленный уровень» - что думает ваш работодатель? Это обширная наука - небольшая фокусировка поможет. –

+0

Спасибо за комментарий, мой вопрос на самом деле о том, как привлечь внимание, о котором вы говорите. Я обновил вопрос, чтобы попытаться это разъяснить. – sharkin

+0

Вас интересуют «базы данных в целом» или конкретный продукт базы данных? Там обычно лучше доступный материал, который зависит от поставщика. – RobS

ответ

3

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

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

Я не делают никаких требований полноты или минимальности, либо.

+0

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

+0

Это зависит от того, что вы подразумеваете под «оптимизацией базы данных». Я упомянул «организацию хранения», о которой, как вы думаете в своем втором предложении, может быть то, о чем вы думаете. Существует несколько различных организаций хранения. Одна из основных, но очень эффективных - использование B-Tree или B * -Tree организаций; вы также найдете широко распространенный хеш. Кроме того, существуют более специализированные организации, такие как индексы только индексов или индексы бит-карты, или индексы R-Tree (для пространственных данных). Как структура общего назначения, варианты B-Tree довольно много избивают. –

+0

Хорошо. Большое спасибо! – sharkin

9

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

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

+2

Из интереса: что такое «правильная» реляционная база данных? – Tomalak

+2

Тот, кто полностью и правдиво реляционный. SQL нет. – 2009-04-15 11:31:21

+1

О, я вижу.Является ли ваш проект общедоступным, могу ли я загрузить его где-нибудь? – Tomalak

1

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

1

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

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

4

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

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

1

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

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

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

Удачи :-)

3

Получите больше от грязи CJ Дейта Database In Depth: Relational Theory for Practitioners если его An Introduction to Database Systems не достаточно грязный для вас.

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

0

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

0

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

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

-don

1
2

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

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

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

Еще одна высокая Масштабируемость ...

http://highscalability.com/

Они попадают в каждую сферу децибелах.

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

1

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

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

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

2

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

1

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

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

  1. денормализации вашу базу данных, так, чтобы уменьшить количество таблиц присоединиться
  2. Добавление индексов
  3. фильтрации должно быть сделано так, что вы первый удалите самую большую из несовпадающих данных, затем вы вишневы выбираете следующее условие для уменьшенного набора. Лучше перейти от 100 значений -> 10, соответствующих первому условию -> 1, соответствующего первому и второму условию, чем 100 значений -> 80, соответствующее второму условию -> 1, соответствующему первому и второму условию. Кажется тривиальным, но важно иметь в виду.
  4. деляти дрвластвуй девиз для масштабируемости. Если у вас есть что-то, что масштабируется нелинейным способом, скажем O (N^2), имеет смысл держать N как можно ниже, и вы должны разбить свой набор данных на более мелкие наборы, если они независимы, и вы можете выработать разбиение. Примером этого является очертание, обычно используемое для хранения баз данных пользователей на крупных социальных сайтах. (NB: пример, я бы не реализовал его таким образом) Вместо того, чтобы иметь огромную базу данных со всеми пользователями, у них есть 26 серверов (по одной для каждой буквы алфавита), затем они помещают все псевдонимы с одинаковой первой буквой на том же сервере. Это имеет следующие преимущества:

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

0

Существует только одна строгая методика концептуального моделирования схемы реляционной базы данных, о которой я знаю (и я потратил много времени на поиск). Это смутно называется «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

и вот plugin for Visual Studio

1

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

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

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

1

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

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

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

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

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

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

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

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

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

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

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

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

0

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

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

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

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

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

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

0

Вы можете начать с чтения одной из (почти) последних обзорных, которые сосредоточивают внимание на основах и тенденциях в области баз данных: The anatomy of databases

Смежные вопросы