«Use the index, Luke» подборка книг по SQL и теории баз данных


Оглавление (нажмите, чтобы открыть):

Laravel. Работа с высоконагруженными БД: MySQL, PostgreSQL

Доброго времени суток.

Все проекты разрабатываю на Laravel 5.4. Все запросы к БД выполнял методами фреймворка, как например: ->where(‘id’,1), чистых SQL-запросов не использовал (возможно они не нужны и при высоконагруженности, а важны принципы или подход) и до недавнего времени не приходилось работать с высоконагруженными (например, > 12 млн записей в таблице) базами данных. Теперь хочу в этом разобраться, понять основы.

Что порекомендуете изучить, может какой-то определенный материал, или какой-то курс пройти? В основном использовал MySQL, также хочу освоить PostgreSQL.

05.08.2020, 19:45

Приглашаем web-программиста (php, MySQL, Javascript) для работы с высоконагруженными проектами.
Приглашаем web-программиста (php, MySQL, Javascript) для работы с высоконагруженными проектами. .

В Laravel 5.6 / PostgreSql 9.6 сгруппировать таблицу
Всем привет! В Laravel 5.6 / PostgreSql9.6 нужно сгруппировать таблицу songs по полю title которых.

MySQL vs PostgreSQL
Нужно перенести систему работающую с MySQL на PostgreSQL. Хотелось бы почитать о различии типов.

Синхронизация PostgreSQL+MySQL
Здравствуйте. Ситуация следующая в компании для которой делается программа на С# основные данные.

PostgreSQL или MySQL?
Не холивара ради, а только для конкретной задачи: Есть один комп, на нём крутить БД. К нему по.

10.08.2020, 17:14 2

и почитывать: хабр, sql.ru

во время обучения тщательно распихиваем инфу по файлам в отдельной дире и бережём как зеницу ока

Посоветуйте хорошую книгу по MySQL.

Простенькие запросы писать могу, надо мочь писать не простенькие.

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

Лучше всего сначала почитайте теорию по стандарту.
Например SQL a beginners guide. А потом документацию по PostgreSQL/любой другой реализации.

А на русском нет?

Лучше чти на английском.
Я пару переводов на русский посмотрел и они мне не понравились.

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

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

Есть ли описания алгоритмов поиска в БД по не ключевому атрибуту?

Принцип везде один: если есть возможность использовать индекс, он используется, если же индекса нет или БД считает его использование не рациональным, осуществляется полное сканирование.

Алгоритмы, как и сами типы индексов бывают разными, в основном B-дерево, хеш таблица, иногда R-дерево (может и k-d дерево тоже встречается, я так сильно не углублялся).


Так вот, вам интересны эти самые алгоритмы? Тогда следует читать «Исскуство программированя» Дональда Кнута. Если же нужны конкретные реализации в серверах БД, то официальную документацию по интересующей вас БД (не забываем, что самая лучшая документация — это исходники).

SQL Indexing and Tuning e-Book

A site explaining SQL indexing to developers—no crap about administration.

SQL indexing is the most effective tuning method—yet it is often neglected during development. Use The Index, Luke explains SQL indexing from grounds up and doesn’t stop at ORM tools like Hibernate.

Use The Index, Luke is the free web-edition of SQL Performance Explained. If you like this site, consider getting the book. Also have a look at the shop for other cool stuff that supports this site.

SQL Indexing in MySQL, Oracle, SQL Server, etc.

Use The Index, Luke presents indexing in a vendor agnostic fashion. Product specific notes are provided like here:

Use The Index, Luke covers SQL indexing for IBM DB2. Tests were conducted with DB2 for Linux, UNIX and Windows, (LUW) V10.5 through 11.1.

Use The Index, Luke covers SQL indexing for MySQL. Tests were conducted with MySQL 5.5 through 8.0.18.

Use The Index, Luke covers SQL indexing for the Oracle database. Tests were conducted with Oracle 11g and 12c.

Use The Index, Luke covers SQL indexing for PostgreSQL. Tests were conducted with PostgreSQL 9.0 through 11.

Use The Index, Luke covers SQL indexing for Microsoft SQL Server. Tests were conducted with SQL Server 2008R2 through 2020.

Have more questions about SQL indexing or tuning? No problem—have a look at my training and tuning services at winand.at.

Table of Contents

Preface — Why is indexing a development task?

Slow Indexes, Part I — Two ingredients make the index slow

The Where Clause — Indexing to improve search performance

Functions — Using functions in the where clause

User-Defined Functions — Limitations of function-based indexes

Bind Variables — For security and performance

Index Combine — Why not using one index for every column?

NULL in Indexes — Every index is a partial index

Dates — Pay special attention to DATE types


Smart Logic — The smartest way to make SQL slow

Math — Databases don’t solve equations

Data Volume — Sloppy indexing bites back

System Load — Production load affects response time

Nested Loops — About the N+1 selects problem in ORM

Hash Join — Requires an entirely different indexing approach

Sort-Merge Join ‌— Like a zipper on two sorted sets

Sorting and Grouping — Pipelined order by : the third power

Selecting Top-N Rows — if you need the first few rows only

Fetching The Next Page — The offset and seek methods compared

Window-Functions — Pagination using analytic queries

Insert — cannot take direct benefit from indexes

Delete — uses indexes for the where clause

Update — does not affect all indexes of the table

About the Author

Markus Winand is the SQL Renaissance Ambassador. He is on a mission to introduce developers to the evolution of SQL in the 21st century. Markus can be hired as trainer, speaker and consultant via winand.at.

Buy his Book on Amazon

The essence of SQL tuning in 200 pages

Paperback and PDF also available at Markus’ store.

Hire Markus

Markus offers SQL training and consulting for developers working at companies of any size.
Learn more »

Базы данных, игры и другие колониальные товары

oracle, postgresql, photos, books, книги, фото


SQL Performance Explained. Markus Winand.

Есть очень хороший сайт, посвященный вопросам работы индексов в реляционных БД, http://use-the-index-luke.com/. Эта книга написана его создателем. Название несколько вводит в заблуждение, к сожалению, это не общая работа о производительности БД и вопросы секционирования, работы планировщика запросов, кэши и прочее здесь не рассмотрены — только устройство индексов, их использование и влияние на скорость. Но это важная тема и разобрана она на отлично. Пожалуй, лучшей работы общего характера сложно и желать.

Маркус начинает с объяснения того, что такое индекс, затем переходит к его использованию в запросах к одной таблице и показывает влияние на масштабируемость в зависимости от структуры. Далее показано, какие существуют типы соединения таблиц и как их можно оптимизировать. Завершается книга влиянием индексов на операции записи и кратким руководством по чтению планов запросов. Между делом разобраны еще несколько тем. (кластеризация, функциональные индексы и пр.). Все подробно иллюстрируется примерами на Oracle, во многих местах есть отсылки к особенностям Postgresql, другие СУБД освещены менее подробно. Увы, но материал почти полностью дублирует сайт автора. Впрочем, это не делает его хуже.

На выходе мы имеем прекрасную обзорную работу по индексам и немного — по оптимизации производительности запросов. Прочесть её безусловно стоит, но поскольку всё или почти всё выложено Винандом в открытый доступ, покупать имеет смысл только, если вы хотите поблагодарить автора за его труды.

Tag: Use-The-Index-Luke

jOOQ Tuesdays: Markus Winand is on a Modern SQL Mission

Welcome to the jOOQ Tuesdays series. In this series, we’ll publish an article on the third Tuesday every other month where we interview someone we find exciting in our industry from a jOOQ perspective. This includes people who work with SQL, Java, Open Source, and a variety of other related topics.

We are excited to talk with Markus Winand in this sixth edition. Markus is the author of the popular book SQL Performance Explained and the even more popular website Use The Index, Luke, and we’re thrilled to see that he’s pulling off another stunt:

Hi Markus – You have recently launched modern-sql.com. What is your goal with this website?

My goal for modern-sql.com is to create a textbook and reference about the SQL goodies you didn’t learn in school or university. Interestingly, online manuals about these features are pretty sparse. They come in two fashions: blog posts and vendor documentation. Blog posts are usually one-off events covering a particular feature or use case. There are many great blogs out there – the jOOQ blog being one of them – but there is no one I could recommend to learn all about recent SQL features. Vendor documentation, on the other hand, is mostly a reference about syntax—quite often even a bad one: they often don’t mention standard compliance at all and tend to follow a “proprietary features first” approach.

Мастер Йода рекомендует:  Использование CSS классов – удобный путеводитель

The consequence is that SQL market is very fragmented: besides SQL-92, there is no obvious base that is common to all databases. This becomes particularly evident on the job market: job offers either require just SQL—meaning good old relational SQL—or they require experience with a specific product. That’s pretty much the norm nowadays and nobody questions it. However, how would you think about this job opening: “Google Chrome Web Developer.” Web developers can’t choose the client’s browser. Many tried, but failed. Remember “optimized for XYZ”? That’s why web developers demanded standard conformance from browsers over the past decades. Just having launched a new website I can say that CSS conformance has improved drastically over the past five years. Ultimately, I’d like the same thing to happen for SQL. I hope that modern-sql.com sparks interest in standard conforming SQL so that developers also start to demand standard conformance from the database vendors. Quite an ambitious goal.

Last year, you’ve gone into battle against the SQL OFFSET clause. Want to shed some light on the background of that campaign?

The most striking problem with OFFSET is that it is generally used for an invalid use case: pagination. In this case, OFFSET is used to skip over a number of rows in the intention to find the rows following the previously selected ones. However, OFFSET does per definition not return the rows following one that was selected earlier, but just discards the first N rows of the result. Coincidentally, OFFSET yields the expected result if the data has not changed in the meanwhile—a case that is pretty common during development. But as soon as rows are added or deleted, discarding a fixed number of rows just doesn’t give the right result. The correct approach is to remember the last row fetched and use this data in a WHERE clause to select the rows following. This approach is explained in detail at http://use-the-index-luke.com/no-offset.

Besides the fact that OFFSET cannot be used to implement correct pagination, OFFSET is also bad for performance. OFFSET is wrong and slow. What else do you need? As a matter of fact, the only valid use case I know for OFFSET it to implement SLEEP in SQL—not that I ever need that. Unfortunately, OFFSET made it into the SQL standard in 2011. I consider this the worst mistake in recent history of SQL because it can’t be corrected. The only good part is that it is an optional feature—vendors don’t need to implement for standard conformance. Nevertheless, Oracle and Microsoft just recently added OFFSET to their SQL databases.

You’ve written a very popular book on SQL Performance called SQL Performance explained. How does it compare to other SQL books and why should our readers buy it?

I’ll start with the second question. First of all you must know that the full content of SQL Performance Explained is available for free at http://use-the-index-luke.com/. Most people I’m asking why they bought the book did so because the like the web site. They bought the book either to support my work on Use The Index, Luke (greatly appreciated!) or, more importantly, to finally read the book from cover to cover. A typical answer I get goes along these lines: “I knew Use The Index, Luke for years and have read many articles there, but I finally wanted to read everything from the beginning to end.”

Now coming to the first question why the world needed another SQL performance tome: it didn’t. Therefore, I wrote a very small book that can be read in less than a day. I focused on the basic concepts, which are the same in most databases, and boldly skipped less common special cases. Its shortness is also most appreciated in the reviews. On the other hand, the book has occasionally being criticized as being incomplete—probably because the sub-title reads “Everything developers need to know about SQL performance”. Personally, I think these critiques somehow proof my point: Obviously, Java, PHP or .NET developers don’t need to know as much about SQL performance as database performance consultants. When writing for such an audience, you must skip a lot.

Where do you see SQL in 10 years from today?

I hope that the temporal features of SQL:2011 (see here) become commonly available—also in free open source databases. At the moment, they are only available in commercial databases—even there the completeness and standard conformance varies. I would also hope that the SQL standard finds a way to cope with the current trend that every database vendor adds its own proprietary set of JSON functions. Unfortunately, it might be too late for that already.

However, my greatest hope is that developers realize that SQL is not stuck in 1992. The standard has added many useful features since than. Most databases offer a good part of these features. It’s really just our perception of SQL that got stuck in 1992.

Learn more about Markus’s work

… Markus is giving his Modern SQL talk at conferences. Learn more about it here:

SQL vs NoSQL: как насчет других проблем, чем ACID и масштабируемости?


В последнее время я прочитал немало статей, описывающих SQL и NoSQL с обеих сторон разрыва, таких как http://use-the-index-luke.com/blog/2013-04/whats-left-of-nosql. Эти статьи очень часто затрагивают предметы, такие как ACID и масштабируемость. Тем не менее, ряд вопросов, которые я обычно имею с SQL, как правило, редко упоминаются в этих статьях, и мне было интересно, почему и что это связано с тем, что я не совсем понимаю SQL. Если кто-нибудь сможет просветить меня, по крайней мере частично, по одному или нескольким из следующих пунктов, я бы очень признателен.

Мои проблемы с SQL:

  • SQL по своей сути небезопасен: SQL — это язык, который был сделан для вставки и не имеет каких-либо методов предотвращения вставки кода вместо данных. Единственный способ предотвратить вставку — полностью изолировать SQL от приложения, используя его. Почему это еще не было разрешено в самом SQL?
  • Кажется, что SQL был сделан для наименьшего размера памяти для данных, содержащихся в нем. Хотя это все еще имеет большой смысл для огромных объемов данных, оно больше не подходит для небольших баз данных или делает это?
  • SQL заставляет все подогнать двухмерную реляционную модель, а конкретные таблицы отношений — для других измерений. Для меня это представляет собой две проблемы:
    • согласованность данных полностью зависит от таблиц отношений
    • данные очень трудно понять людям в случаях сбоев.
  • SQL не поддерживает историю, поскольку по умолчанию она выполняет деструктивные обновления: есть, конечно, всевозможные способы создания истории, но для этого требуются специальные письменные материалы с дополнительными таблицами и использование штампов времени или запись новый рекорд для каждого изменения, что приводит к экспоненциально растущим размерам таблиц.
  • SQL, похоже, предпочитает потерю данных для потери согласованности: если возникает ошибка или потеря согласованности, единственным способом восстановления ситуации в постоянном состоянии является использование резервной копии, что означает, что последние изменения будут уничтожены. Это отчасти из-за отсутствия истории (см. 4), но также из-за отсутствия читаемости для человека нет реального способа заставить человека исправить ошибки.
  • Особенно в веб-среде использование SQL обычно означает, что модели создаются часто более одного раза. В обычном (простом) веб-приложении PHP дважды: один раз в PHP, один раз в SQL. В веб-приложении полного стека три раза: один раз в клиентском приложении, один раз в промежуточном программном обеспечении и один раз в базе данных SQL (если ORM не используется). Из-за разных языков программирования и различий типов между ними это означает, что между этими моделями существует множество возможных конфликтов. Я знаю, что ORM, такие как ActiveRecord и Django, решают хотя бы часть этих проблем, но объем дополнительной работы вам еще нужно сделать, потому что таблица SQL содержит VARCHAR (25) и ни один из используемых языков (JavaScript, Ruby, PHP, Perl, Python и т.д.) Знают, что такая конструкция огромна.
  • Изменения структуры данных, по-видимому, рассматриваются как проблема согласованности: если что-то меняется в структуре данных, изменения таблицы применяются к каждой существующей записи в этой таблице, даже если запись не имела этого поля изначально и независимо от того, для этой записи имеет смысл иметь это поле. Набор этих изменений приводит к автоматическим переходам, которые добавляют еще один уровень возможных проблем, особенно в отношении согласованности.
  • Смешивание логики хранения и логики приложения: SQL, похоже, хочет сожрать части логики приложения в качестве хранимых процедур (CouchDB также делает это через представления). Хотя я понимаю, что для некоторых типов операций вам нужна серверная сторона и очень строго контролируемые процедуры, я не понимаю, почему они хранятся в базе данных и как таковая часть механизма хранения, а не являются частью приложения ( промежуточный слой).

Я знаю (но не очень хорошо знаю) такие вещи, как PostgreSQL Hstore, но я не вижу полностью, как это решает то, о чем говорилось выше. Спасибо за любые идеи!

Является ли SQL по своей сути небезопасным?

Мастер Йода рекомендует:  Visual Studio Code стал частью Python-дистрибутива Anaconda

Я думаю, вы имеете в виду SQL Injections, который является одной из самых опасных уязвимостей безопасности вообще.

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

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

«наименьший размер памяти возможно»

Извините, у меня нет этого вопроса.

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

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

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

Доступ к данным из многих таблиц должен выполняться с помощью объединений и аналогичных операций SQL. SQL делает больше, чем хранение и извлечение данных с использованием способа 1:1, он предоставляет инструменты (объединения, подзапросы, операции набора. ) для преобразования нормализованных данных в форму, наиболее подходящую для конкретной задачи. Это делается намеренно во время выполнения, потому что задачи не обязательно должны быть заранее известны. С другой стороны, характер данных данных считается статическим, так что сохранение его нормализованной моды является допустимым. Это очень важная ключевая концепция реляционной модели и SQL: характер данных не изменяется, так что он должен быть постоянным. Как вы используете эти данные, они широко варьируются и часто меняются с течением времени, поэтому это необходимо сделать динамичным. Это, конечно, очень обычная задача, так что имеет смысл иметь прочный инструмент, чтобы сделать его легким. Мы называем этот инструмент SQL;) Правило DRY может быть выполнено с помощью представлений или CTEs, но оба могут повредить потому что реализация не очень оптимизирована для этого (что я открыто критикую!).

Сохранение данных, согласованных во многих таблицах, в основном выполняется с помощью ограничений.


Обработка предполагаемых «несоответствий» (истории) была наконец покрыта SQL:2011: это позволит запросить «AS» и предоставить также инструменты для поддержания временной консистенции ( например, действительность одной строки может не совпадать с действительностью другой строки). Вероятно, довольно плохо, что потребовалось 40 лет или около того, чтобы придумать решение для этого. И я даже не знаю, когда это будет общедоступно!

Я думаю, что эта часть в значительной степени верна для каждой системы: «данные очень трудны для людей, чтобы иметь смысл в случаях сбоев» (мой акцент). Однако, я думаю, вы можете иметь в виду, что трудно исследовать проблемы, потому что требуемые данные могут быть распределены по нескольким таблицам. Ответ SQL для этого: VIEWs, которые в основном просто сохранены. Однако в зависимости от диапазона базы данных VIEW могут возникать проблемы с производительностью. Это, однако, ограничение некоторых диапазонов базы данных, а не ограничение SQL или реляционной модели.

Я уже упоминал выше (SQL: 2011).

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

Инструментами для борьбы с ним являются триггеры или ORM. Если вы хотите быть уверенным, что никто не выполняет «деструктивное обновление», вы можете просто отменить права UPDATE на этой таблице (а также DELETE на стороне сохранения).

«предпочитают потерю данных для потери согласованности:»

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

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

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

В моих наблюдениях это абсолютно верно: у меня недавно было задание преподавать SQL для поддержки персонала, чтобы они могли расследовать случаи непосредственно в базе данных. Они не были программистами, но поняли SQL довольно быстро. И я думаю, что здесь вызывается ваш «человеческий» аргумент: в чем у них были проблемы с навигацией реальной реляционной модели, состоящей из нескольких сотен таблиц. Но эта проблема была быстро решена, попросив разработчиков предоставить представления для некоторых общих задач, которые включают более чем несколько таблиц. Присоединение к этому представлению было уже не проблема.

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

Несоответствие импеданса объектов/реляций

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

Изменения структуры данных

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

Это также довольно хорошо обсужденный аргумент: schema vs. «schema less». Выберите свой вкус. «Schema less» довольно часто означает «не предоставляет инструменты управления схемой», тем не менее вам приходится справляться с тем, что мы иногда хотим добавить дополнительные свойства к существующей сущности. RDBMS предоставляют инструменты для этого: новые столбцы могут быть обнуляемыми или иметь значения по умолчанию. Более резкие изменения, такие как перемещение одного атрибута в дополнительную таблицу (например, 1: n), можно выполнить с помощью CREATE AS SELECT. Возможно, вы даже представите представление совместимости, которое по-прежнему передает данные так, как должно быть (как будто перемещенный атрибут все равно будет храниться в таблице). После того, как вы изменили схему, ваше приложение может полагаться на его ограничения (например, наличие столбцов или допустимость ограничений). Это довольно много вещей, которые база данных может сделать для вас в чрезвычайно надежной манере. Вам больше не нужно заботиться о своем приложении.

Аргумент, о котором вы не говорили, заключается в том, что эти изменения схемы часто связаны с простоем. Это окончательно верно для прошлого, а в некоторой степени и сегодня. Например. MySQL представляет онлайн ALTER TABLE только в 5.6 недавно. Однако это довольно частое ограничение реализации, а не проблема, связанная с реляционной моделью или SQL. Даже некоторые более сложные изменения (например, перемещение атрибута в другую таблицу) можно сделать онлайн, когда все сделано правильно и тщательно спланировано (я сделал это с одной из дорогостоящей базы данных, которая предоставляет все необходимые для этого инструменты). Как правило, это сохранение кода миграции из вашего приложения и копирование в базе данных с ним. После миграции у вас не должно быть артефактов миграции в БД или в коде приложения. Конечно, бывают случаи, когда время простоя неизбежно (я думаю;).

«Смешение логики хранения и логики приложения»

SQL фактически делает совершенно противоположное: SQL полностью абстрагирует слой хранения.

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

Второй аргумент — это, конечно, чрезмерное использование ORM снова и политики, которые запрещают использование реального SQL в приложении.

«Use the index, Luke»: подборка книг по SQL и теории баз данных

22 авг 2020 . Скачать. Данная книга посвящена теории баз данных и систем . Database Design and Implementation. Скачать. В этой книге пошагово .


Много бесплатных книг по программированию / Хабр

25 авг 2013 . Flex. Getting started with Adobe Flex (PDF) . Developing Time-Oriented Database Applications in SQL · Use The Index, Luke!: A Guide To .

Базы данных — Все для студента

Bhattacharya A. Fundamentals of Database Indexing and Searching. pdf. Раздел : . Captain Fidel A. Six-Step Relational Database Design. pdf . Coronel C., Morris S. Database Systems: Design, Implementation, and Management. pdf.

Бесплатные материалы для программистов

20 фев 2020 . Agile Android Software Development — Etienne Savard (PDF, epub, mobi); Android 4 App . Differential Equations — Paul Dawkins (PDF, use form to download); Discrete . Онлайн-курс Algorithm Design and Implementation; Онлайн-курс Berkeley’s CS 70: . A Guide To SQL Database Performance .

SQL Server — Все для студента

Код примеров к выложенной здесь книге в формате PDF, EPUB, MOBI. This book . Pro SQL Server Relational Database Design and Implementation. epub.

Data Science -профессия будущего (и настоящего?)

25 сен 2013 . Parallel databases, parallel query processing, in-database analytics . understanding multi-dimensional database design and implementation.

Третья нормальная форма — Википедия

Третья нормальная форма (англ. Third normal form; сокращённо 3NF) — одна из . Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. . Печать/экспорт. Создать книгу · Скачать как PDF · Версия для печати .

PicoDBMS: Val >www.vldb.org

storage [Gem99]), the need for database management arises. . Validate our design by building a complex database application . implementation of both select and join indices. ГиДYЕa . downloaded on any Java-enabled terminal. It allows.

Мастер Йода рекомендует:  Python digest #1. Новый формат зависимостей и авторизация с помощью Flask

(PDF) Social Navigator: Implementation of the.

Full-Text Paper (PDF): Social Navigator: Implementation of the Software Infrastructure . Article (PDF Available) · June 2020 with 39 Reads . Download full-text PDF . Design considerations for a personalized wheelchair navigation system . The environment includes several applications utilizing unified database and .

Обсуждаем phpBB 3.0 Olympus (ex-phpBB 2.2) — phpBB Guru .

15 май 2004 . Где можно скачать перевод phpBB3 на русский? . admin SQL query review and re-design + database review Implementation of subforums .

Database Design and Implementation Pdf Free Download | e-Books

Download Database Design and Implementation 1st Edition Pdf.

Database Systems: Design, Implementation, and. — PDF Drive

Download PDF. “ If your life’s work can be accomplished in your lifetime, you’re not thinking big enough. ” ― Wes Jackson.

How To Download Database Design And Implementation For Free?


[download] ebooks database design and implementation pdf.

How To Download Database Design And Implementation For Free?

[download] ebooks database design and implementation pdf.

Database design and implementation edward sciore pdf download

And edward design database implementation sciore pdf. 98-364 database administration fundamentals microsoft. if you do not see them here, chances are we. creating value in a dynamic business environment, 9/e by

How To Download Database Design And Implementation For Free?

[download] ebooks database design and implementation pdf.

Database Systems: Design, Implementation, & Management | PDF.

How To Download Database Design And Implementation Sciore

Why should be database design and implementation sciore solutions? As a book lover, you must know that enjoying the book to read should be relevant to how you exactly need now.

Database Processing: Fundamentals, Design, and Implementation.

Click to download. True PDF, AZW4.

How To Download Database Design And Implementation Sciore

Learn more about database design and implementation sciore solutions and you can really find the advantages of reading this book. The provided soft file book of this PDF will give the amazing situation.

Советы и рекомендации для ускорения работы SQL

Это основы SQL Функция и ключевые слова.

Есть ли советы или трюки, чтобы ускорить ваш SQL ?

Например; У меня есть запрос с большим количеством ключевых слов. ( AND, GROUP BY, ORDER BY, IN, BETWEEN, LIKE . и т.д.)

Какое ключевое слово должно быть сверху в моем запросе? Как я могу это решить?

Какой из них быстрее? Зависит от того, что?

sql database tsql

4 ответа

4 Решение Ronnis [2011-03-28 17:16:00]


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

Есть только вещи, о которых нужно знать, но их обычно нельзя свести к:

  • Использовать функцию X
  • Избегайте функции Y
  • Модель, подобная this
  • Никогда не моделируйте как , что

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

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

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

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

Теперь, какую конкретную рыбу вы хотите поймать?

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

  • Можно ли переписать запрос в соответствии с индексированным представлением
  • Какие индексы доступны, который охватывает один или оба столбца NUMBER и DATE и в каком порядке они существуют в этом индексе
  • Предполагаемая избирательность ваших предикатов, которая в основном означает оценочный процент строк, соответствующих вашему предикату. Чем меньше%, тем вероятнее, что оптимизатор должен эффективно использовать ваш индекс.
  • Фактор кластеризации (или любое другое имя на SQL Server), если факторы SQL Server, связанные с затратами на запрос. Это связано с тем, как порядок элементов индекса выравнивается с физическим порядком строк таблицы. Лучшее выравнивание = снижает затраты для более высоких% строк, полученных с помощью этого индекса.

Теперь, если единственные значения, которые у вас есть в столбце NUMBER, равны 156, 646, и они довольно равномерно распределены, индекс будет бесполезен. Полное сканирование будет лучшей альтернативой.
С другой стороны, если это уникальные порядковые номера (подкрепленные уникальным индексом), оптимизатор будет выбирать этот индекс и отбирать запрос оттуда. Аналогично, если строки, имеющие DATE между первым и вторым январем 2011 года, составляют достаточно мало% строк, будет рассмотрен индекс, ведущий с DATE.

Или, если вы включаете order by NUMBER, DATE , в уравнение входит другой параметр; стоимость сортировки. Индекс на (NUMBER, DATE) теперь будет казаться более привлекательным для оптимизатора, потому что, хотя это может быть не самый эффективный способ приобретения строк, сортировка (которая стоит дорого) может быть пропущена.

О компании

Структурированный язык запросов SQL(Structed Query Language) — формальный язык программирования для манипуляции данными в реляционных базах данных. Чтобы задать хороший вопрос, используйте инструкцию в полном описании метки. Вопрос должен содержать структуру таблиц, тестовые данные и примеры запросов, иллюстрирующих проблему. Указывайте используемую СУБД. Желательно использовать ANSI SQL запросы.

SQL (Structured Query Language) — структурный язык запросов. Используется в системах управления реляционными базами данных (СУБД).

Что должно быть в вопросе по SQL?

Вопросы по возможности должны содержать структуру таблиц, тестовые данные и примеры запросов, иллюстрирующих проблему. Кроме того, в метках стоит указывать вид СУБД, которая используется, например, mysql, postgresql, oracle, sql-server.
В ответах следует стараться использовать ANSI SQL запросы.

Базовые понятия

Одно из подмножеств SQL называется DDL (data definition language) — язык описания данных, который используется для действий над структурой данных: создание, изменение, удаление таблиц, представлений, индексов, и т. д. Основные команды DDL:

  • CREATE — создает объект базы данных, например, таблицы в базе данных;
  • ALTER — изменяет структуру существующего объекта базы данных каким-либо образом (добавляет колонки, меняет тип колонок, добавляет ограничения. );
  • DROP — удаляет объект из базы данных, например таблицу, как правило безвозвратно.


Другое подмножество SQL называется DML (data manipulation language) — язык манипуляции данными. Основные команды DML:

  • SELECT — формирует выборку из одной или нескольких таблиц базы данных;
  • INSERT — добавляет данные в таблицу;
  • UPDATE — изменяет данные в существующих записях таблицы;
  • DELETE — удаляет записи из таблицы.

Следующее подмножество — DCL (data control language) — язык определения доступа к данным, содержит команды:

  • GRANT — наделяет пользователя базы данных определенными привилегиями для выполнения конкретных действий (выборки, изменения данных, изменения структуры данных и т.д.);
  • REVOKE — аннулирует ранее выданные разрешения для пользователя.

И подмножество TCL (transaction control language) — язык управления транзакциями. Содержит команды:

  • COMMIT — фиксирует действия над данными, после начала транзакции;
  • ROLLBACK — отменяет изменения, внесенные после начала транзакции;
  • SAVEPOINT — делит транзакцию на более мелкие участки.

На протяжении множества лет разработчики разных систем управления базами данных, постоянно развивая свои продукты, добиваясь при этом простоты использования и скорости выполнения, реализовали собственные диалекты SQL. В результате получилось, что все используют SQL, но со специфическими изменениями, и один и тот же запрос в разных СУБД может работать по-разному, а может и вовсе не работать из-за несовместимости синтаксиса.

Стандарты ISO/IEC (или ANSI) существенно помогают в разрешении таких ситуаций, но с переменным успехом. Да, запросы написанные по стандарту должны быть переносимыми между разными СУБД, однако никто не гарантирует одинаковой производительности. И даже производительность запроса с использованием своего диалекта может отличаться от производительности ANSI запроса.

Большинство СУБД имеют свой диалект для написания хранимых процедур. Например, в Oracle это PL/SQL, в PostgreSQL — PL/pgSQL. Для остальных запросов обе СУБД используют SQL. Поэтому, если ваш вопрос относится к проблемам, связанным с хранимыми процедурами, используйте также метки plsql и plpgsql. В Microsoft SQL Server используется Transact-SQL и для обычных запросов (DML) и для написания хранимых процедур, для таких вопросов стоит добавить метку t-sql.

Рекомендации по добавлению меток

Данная метка предназначена для общих вопросов, связанных с SQL, а также в качестве дополнения к меткам для вопросов, связанных с конкретными СУБД. Например, вопросы по Microsoft SQL Server должны быть с меткой sql-server, а вопросы по MySQL должны быть с меткой mysql. Кроме того, для уточнения какие функции СУБД используются или могут быть использованы, можно добавлять метки, содержащие версию, например oracle11g, sql-server-2008.

Пожалуйста, прочитайте краткое описание о стандарте SQL (SQL-92 наиболее полно поддерживается большинством СУБД) или обратитесь к полному изданию (англ.).

Полезные ресурсы

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

Бесплатные книги по SQL

На русском языке:

На английском языке:

Бесплатные онлайн курсы по SQL/Базам данных

На русском языке:

На английском языке:

Язык кода (используется для выделения синтаксиса): lang-sql

Добавить комментарий