Что я должен знать о базах данных?

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

• Для чего нужны базы данных?
• Базовые операции CRUD
• SELECT запросы с JOINs
• Нормализация
• Базовое индексирование
• Ссылочная целостность с Ограничениями внешнего ключа
• Основные ограничения проверки

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

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

Примеры:

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

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

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

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

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

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

Мои 2 цента

Я вижу объявления о вакансиях, в которых запрашиваются знания 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. Это, а также потому, что большинство слишком ленивы, чтобы нанимать для разведки, вместо этого они прибегают к «У нас есть X, черт возьми, нам нужно нанять кого-то, кто знает X!» мем. Различия на самом деле не так уж и сложно понять тем, кто часто посещает StackOverflow. Я уверен, что любой здесь может выучить их довольно быстро.

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

Мне очень помогла статья в Википедии .

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

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

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

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

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

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

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

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

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

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

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

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

Даже такая простая вещь, как автоинкрементный первичный ключ, может сильно отличаться в 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 позволяет ВКЛЮЧАТЬ столбцов в индекс, что очень важно для производительности.

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

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

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

• Поддержка триггеров значительно различается. SQL Server имеет ПОСЛЕ и ВМЕСТО .mysql имеет ДО и ПОСЛЕ . В Oracle есть все это и многое другое. Все они ведут себя по-разному.

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

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

ОТРЕДАКТИРОВАНО : Вот ссылка, которую можно описать другим способом ( http://msdn.microsoft.com/en-us/library/aa719740 (VS.71) .aspx ). Но следующие шаги объясняют мою идею выше.

Создайте новый класс .Net, который реализует ваш прежний интерфейс (ILegacy), и новый интерфейс (ISendNotify) с помощью одного метода:

interface ISendNotify 
{
     void SetOnDestroy(IMyListener );
}

class MyWrapper : ILegacy, ISendNotify, IDisposable{ ...

Внутри MyClass создайте экземпляр вашего реального устаревшего объекта и делегируйте этому экземпляру все вызовы из MyClass. Это агрегация. Таким образом, время жизни агрегата теперь зависит от MyClass. Так как MyClass является IDisposable теперь вы можете перехватывать при удалении экземпляра, так что вы можете отправить уведомление от IMyListener

EDIT2 : Там ( http://vb.mvps.org/hardcore/html/countingreferences.htm ) простейший impl IUnknown с отправкой события

Class MyRewritten
    ...
    Implements IUnknown
    Implements ILegacy
    ...
    Sub IUnknown_AddRef()
        c = c + 1
    End Sub

    Sub IUnknown_Release()
        c = c - 1
        If c = 0 Then
            RaiseEvent Me.Class_Terminate
            Erase Me
        End If
    End Sub

Вы правы, что при написании функциональной программы Однако это рассуждение обычно не существует в какой-то уточненной форме (например, тесты), поэтому, как правило, это не тот случай, что функция доказана правильной способом, который является машино- или человек-проверяемым. Конечно, существует возможность использования TDD с функциональными языками (например, с использованием любой библиотеки TDD, совместимой с .NET, с F #) для проверки правильности производных функций, но существуют и другие стратегии тестирования, которые могут быть более уникальными для функциональных языков, например, использование QuickCheck для рандомизированной проверки спецификаций.

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

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