Подтвердить что ты не робот

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

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

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

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

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

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

Спасибо.

Вышеупомянутые понятия мало меняются для MySQL, SQL Server, Oracle и т.д.

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

Операторы CRUD, объединения, индексы. Все они относительно просты в пределах определенного движка. Концепции легко переносятся, если вы знаете разные РСУБД.

То, что я ищу, - это особенности, которые заставили бы работодателя указать конкретный движок, а не "опыт использования общих движков базы данных".

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Статья в Википедии о индексировании DB.

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

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

Ответ 3

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

Примеры:

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

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

Ответ 4

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

  • Row vs page vs escalation блокировки таблиц при выполнении нескольких сложных объединений подразумевает иногда выполнение очень разных вещей на разных поставщиках dbs. Именно здесь теория действительно поражает асфальт и часто не интуитивно понятна.
  • Различия между тем, как курсоры лучше всего использовать для различных реализаций db поставщика.
  • Нечетные вещи в хранимых вариантах языка proc, например, как лучше всего обрабатывать случаи сбоев
  • Различия в том, как временные таблицы и представления лучше всего использовать в зависимости от исходных реализаций.

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

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

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

Ответ 5

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

Ответ 6

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

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

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

Мои 2 цента

Ответ 7

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

Я называю SQL Developer. Вы не увидите различий много, когда выполняете работу базы данных мельницы (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. Я уверен, что кто-то здесь может изучить их довольно быстро.

Ответ 8

Даже то, что просто, как первичный ключ с автоматическим приращением, может быть очень различным в 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 или хеш). Это также важное соображение по эффективности.

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

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

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

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

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

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

Ответ 9

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

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