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

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

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

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

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

-don

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

I believe optimization on existing databases could be interesting to dwelve into. I.e. why you should denormalize tables.

Some basic relation algebra is useful knowledge and closely related to set theory.

A very common scenario is having to map ugly databases to an entity model which is not necessary reflected directly in the structure of the DB. Working out which way is best to model the data in your domain can be tricky.

Full text search and XML are subjects that seem to be coming up more and more.

I have no experience with it but I know DB2 (of which there is a trial version) has some crazy new features)

Have fun :-)

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

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

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

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

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

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

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

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

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

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

http://highscalability.com/

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

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

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

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

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

Отказ от ответственности: не является экспертом в проектировании баз данных.

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

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

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

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

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

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

Получите больше грязи от базы данных СиДжея Дейта: Реляционная теория для практиков , если его Введение в системы баз данных не достаточно грязно для вас

Серьезно, эти две книги дадут вам гораздо больше знаний о РСУБД, намного меньше места, чем многие другие профессиональные работники баз данных. В частности, Database in Depth рассматривает, как относиться к базам данных как к реляционным, даже если язык их не поддерживает, и как превратить SQL в язык, близкий к реляционному.

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

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

A whole other area is dimensional modelling and data warehousing.

I had been working with relational modelling for years, and then I read The Data Warehouse Toolkit and received an entirely new view of how it could be used.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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