Что мне нужно знать о базах данных?

Question

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

Я вижу объявления о вакансиях, требующие знания MySQL, MSSQL, Oracle и т. Д., Но я не могу определить, какие будут различия.

Видите ли, как и многие новые программисты, я склонен относиться к своим базам данных как к дампу данных. Большая часть того, что я делаю, сводится к относительно простому SQL (INSERT this, SELECT that, DELETE this_other_thing), который в основном не зависит от используемого мной движка (с небольшими исключениями, конечно, в основном незначительными изменениями синтаксиса).

Может ли кто-нибудь объяснить некоторые распространенные случаи использования баз данных, в которые входит конкретная платформа?

Я уверен, что такие вещи, как хранимые процедуры, очень важны, но (а) они в основном написаны на определенном языке (T-SQL и т. Д.), Который будет отличаться от требований к объявлению работы, чем сама конкретная СУБД, и (б) Я слышал из разных источников, что хранимые процедуры выходят и во многих случаях их не следует использовать в любом случае. Я полагаю, что Джефф Этвуд является членом этого лагеря.

Спасибо.

---

Приведенные выше понятия не сильно различаются для MySQL, SQL Server, Oracle и т. Д.

С помощью этого вопроса я в основном пытаюсь определить важное различие между ними. То есть почему объявление о работе потребовало бы многолетнего опыта работы с MySQL, когда наиболее распространенные варианты использования относительно стабильны на платформах RDBMS.

Операторы CRUD, объединения, индексы ... все они относительно просты в рамках определенного механизма. Понятия легко переносимы, если вы знаете другую РСУБД.

Что мне нужно, так это особенности, которые заставили бы работодателя указать конкретный механизм, а не «опыт использования общих механизмов баз данных».

Answer 1

Я считаю, что основные знания о базах данных должны быть:

• Для какой базы данных?
• Основные операции CRUD
• ВЫБРАТЬ запросы с помощью JOIN
• Нормализация
• Базовое индексирование
• Ссылочная целостность с Ограничения внешнего ключа
• Основные ограничения проверки

Приведенные выше понятия не сильно различаются между MySQL, SQL Server, Oracle, Postgres и другими системами реляционных баз данных . Однако вы найдете другой набор концепций для популярных сейчас баз данных NoSQL , таких как CouchDB , MongoDB , SimpleDB Кассандра , Bigtable и многие другие .

Answer 2

После операторов CRUD, чтобы быть эффективным программистом БД, я думаю, что некоторые из самых важных вещей, которые нужно понять, это операторы JOIN. Понимать разницу между LEFT и RIGHT, OUTER и INNER объединениями и знать, когда их использовать. Самое главное, знать, что база данных фактически создает, когда она выполняет JOIN.

Для меня статья Википедии была очень полезна.

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

Статья в Википедии об индексации БД .

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

Я знаю, что в вашем вопросе вы спрашиваете о конкретных реализациях БД, но если вас воспримут буквально и вы знаете только о SELECT, INSERT, UPDATE и DELETE, тогда Вышеуказанные концепции будут гораздо более ценными, чем изучение тонкостей конкретной реализации.

Answer 3

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

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

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

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

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

Answer 4

Это не просто сохраненные процедуры и функции. Каждая база данных имеет фундаментальные отличия и особенности, которые важно понимать, даже если SQL работает более или менее одинаково.

Примеры:

• Oracle и MySQL обрабатывают блокировку по-разному, в разных ситуациях.
• Oracle не имеет автоинкрементных первичных ключей, таких как MySQL и SQL Server.
• Тонкое поведение, специфичное для поставщика, например, как Oracle выполняет сортировку VARCHAR по-разному в зависимости от локали.

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

Answer 5

Эти базы данных представляют собой закодированные наборы утверждений о фактах. То, что логическая структура таблиц соответствует синтаксической структуре этих «утверждений факта». Эта теория нормализации помогает вам найти наиболее оптимальную логическую структуру базы данных, сводя к минимуму избыточность, то есть сводя к минимуму возможность возникновения противоречий в указанных утверждениях факта. Эти ограничения базы данных на самом деле не что иное, как бизнес-правила, выраженные формально и с точки зрения компонентов базы данных. Это действительно каждое бизнес-правило может быть выражено как ограничение базы данных. Поэтому СУБД может применять любое бизнес-правило, которое вы можете себе представить. Это очень важное различие между логическим дизайном и физическим дизайном. То, что системы SQL и SQL, на самом деле, не очень полезны (и это мягко сказано), чтобы помочь разработчикам распознать это важное различие. То, что системы SQL и SQL, eurhm, существенно лишены (и это мягко говоря) поддержки их ограничений базы данных. Эти два последних примера являются очень хорошей иллюстрацией важности различия между моделью (RM Кодда) и ее реализацией (какой-то конкретной системой SQL). Что касается технологии реляционных баз данных, последние отклоняются еще больше от первого.

И что еще я забыл запомнить.

Answer 6

Даже такие простые вещи, как автоинкрементный первичный ключ, могут сильно отличаться в Oracle , mysql и SQL Server .

Некоторые другие важные отличия:

• SQL Server различает ключ кластеризации и первичный ключ; другой базы данных нет. Этот выбор имеет большое значение для производительности.

• SQL Server допускает синтаксис SET @Total = Total = @Total + Amount для быстрых вычислений, таких как подсчет итогов. mysql позволяет вам использовать переменную пользователя аналогичным образом (я думаю). В других базах данных вам, вероятно, придется использовать коррелированный подзапрос. Огромная разница в производительности.

• SQL Server может генерировать «последовательные идентификаторы GUID» с newsequentialid. Я не уверен, какие другие базы данных имеют эту функцию, но, как и в случае с двумя приведенными выше пунктами, при использовании традиционного GUID существенно влияют на производительность, а не последовательный или гребенчатый.

• Oracle CONNECT BY - это очень полезный и довольно уникальный синтаксис. Общие табличные выражения в SQL Server и mysql похожи, но не совсем одинаковы.

• Поддержка функций ранжирования / упорядочения сильно различается в разных базах данных. Я постоянно публикую здесь ответы, используя ROW_NUMBER. Многие запросы гораздо сложнее написать без этого, но в то же время злоупотребление этим может снизить производительность.

• Поддержка XML по всей карте. Большинство баз данных в настоящее время имеют достаточно хорошую поддержку, но и синтаксис, и семантика совершенно различны для каждой платформы.

• Дата / время обработки могут быть совершенно разными. Oracle имеет несколько различных типов даты / времени, некоторые из которых включают информацию о часовом поясе. В целом, Oracle управляет временными данными намного лучше, чем другие базы данных, и имеет несколько функций, которые вы пропустите при переключении. До недавнего времени у Microsoft не было типов date и time, просто datetime, что было гораздо сложнее нормализовать.

• Пространственные типы различны и / или не существуют в разных базах данных. MySQL предоставляет всю модель OpenGIS; Поддержка Microsoft немного более простая, но все же компетентная. У Oracle это есть, но немного сложно найти информацию, и это своего рода дополнительное дополнение. Я думаю, что DB2 начинает получать это, но поддержка все еще немного неуверенна.

• На самом деле mysql позволяет вам выбрать, как хранить индекс (то есть btree или hash). Это также важный фактор производительности.

• SQL Server позволяет вам INCLUDE столбцов в индексе - очень важно для производительности.

• Oracle позволяет создавать индексы на основе функций, растровые индексы и т. Д. Это может быть довольно сложно обернуть голову.

• Oracle может выполнять «пропуск пропуска» в очень специфических ситуациях, что, я не верю, поддерживается в других базах данных (пока). Это может повлиять на порядок заказа столбцов индекса.

• SQL Server имеет типы / функции / агрегаты CLR. Очевидно, не поддерживается ни в одном другом продукте базы данных.

• Поддержка триггеров значительно различается. SQL Server имеет AFTER и INSTEAD OF. MySQL имеет BEFORE и AFTER. Oracle имеет все это и многое другое. Все они ведут себя совершенно по-разному.

Я уверен, что существует множество различий, но это должно дать вам хотя бы базовую идею о том, почему 5-летний опыт работы с Oracle полностью отличается от 5-летнего опыта работы с SQL Сервер.

Answer 7

Я вижу объявления о вакансиях, требующие знания MySQL, MSSQL, Oracle и т. Д., Но я не могу определить, какие будут различия.

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

При разговоре SQL за пределами стандартов существует 4 различных типа команд. Это:

• Язык манипулирования данными (DML)
• Язык определения данных (DDL)
• Язык управления данными (DCL)
• Язык управления транзакциями (TCL)

Самые большие различия проявляются в последних двух, DCL и TCL. У них есть много специфичных для базы данных нестандартных команд SQL. Первые два, DML и DDL, очень похожи в любой базе данных, в которой используется реляционная модель.

Также крупные поставщики баз данных назвали свои реализации SQL. Вот краткий пример:

• SQL Server: T-SQL
• Oracle: PL-SQL
• PostgreSQL: P-SQL или NG-SQL
• Firebird: IB-SQL
• MySQL: mSQL

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

Я обнаружил, что большинство работодателей не смогут сформулировать это, потому что большинство будет использовать нетехнических менеджеров и / или HR для найма. В основном они говорят техническим менеджерам, что новые сотрудники должны знать технологию X. Это и также, потому что большинство слишком ленивы, чтобы нанимать для разведки, вместо этого они возвращаются к «У нас есть Х, так что, черт возьми, нам нужно нанять кого-то, кто знает Х! мем. Различия на самом деле не так сложны для изучения людьми, которые часто посещают StackOverflow. Я уверен, что любой здесь может выучить это довольно быстро.

Answer 8

Что касается уровня различий между поставщиками, то это потому, что SQL является стандартом (http://en.wikipedia.org/wiki/SQL#Standardization), и поставщики реализуют этот стандарт по-разному.

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

Для хранимых процедур. Я бы согласился, поскольку современные ORM и практики, как правило, делают большее разделение задач, удаляя бизнес-логику из базы данных и считая ее «только» хранилищем.

Мои 2 цента

Answer 9

Не забудьте схемы отношений, первичные и внешние ключи и как они связаны. Для начала я бы использовал MySql и MSSQL, так как они наиболее распространены на рынке. Я беру Oracle как более продвинутый и сложный db