Pull to refresh

Comments 100

На вкус и на цвет.. дыры в голове вместо глаз и общий уровень объяснений "детсад, группа \"Кроха\"".. Барсик, 5 лет, id:3. Никак не понять без картинки, а с картинкой сразу предельно ясно становится.

OMG

От картинок просто тошнит :)

Да если бы вопрос был только в стилистике… тут в погоне за гламурностью ещё и смысл теряется, иногда — полностью.


Берём картинку, которая в статье аж два раза — в начале и в конце:
image


В БД лежат данные приложения...

Какого ещё приложения? Нет у меня никакого приложения, а данные и БД — есть. Смысл сводится к "в базе данных лежат данные"? Отлично, очень ценный постулат, а то мы сомневались, может, там дрова лежат. Здесь бы написать, что делает кучу данных базой, ан нет: главное — гламур.


Она обеспечивает их сохранность ...

Сохранность обеспечивает хороший бэкап. А здесь явно не про сценарии с репликацией. В общем случае — нет, не обеспечивает.


… и позволяет легко и быстро по ним искать.

В общем случае — нет, не позволяет, или не легко, или не быстро. Поиск по данным не является неотъемлемым свойством БД.


Получается, что на заглавной картинке написана чепуха, а этого никто не замечает? Да, именно так, потому что гламур и "звёздные дыры" отвлекают внимание. И именно поэтому не надо знания превращать в комикс, фигня получается.


Например, дальше про foreign key и primary index — просто ерунда написана, такая "околоправда", которая выглядит натурально и способна задурить мозги новичкам, но на деле — чушь.


Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество.

Что? Как, а главное — зачем??


А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ.

Ооо, мой мозг! В "внешний ключ" и "первичный ключ" только слово "ключ" одинаковые, а так они вообще разные и для разного — кому вообще пришло в голову пытаться заменить одно другим?



… но я же ставила foreign key на ФИО + ДР...

Что за "foreign key на ФИО + ДР"? объясните, где такое вообще возможно?


Ага, вы связаны. Значит, в orders всегда есть ссылка на clients

Нет, конечно. Там вполне может оказаться NULL, зависит от CONSTRAINT.


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

господи, сколько неуместных придирок

Было бы неплохо аргументировать..

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

СУБД может эти заниматься, но совершенно не обязана. SQLite, например, очень даже СУБД. А так -- можно и Clarion взять в качестве образца СУБД, и ещё кучу фич запихнуть в определение.

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

Если даётся общее определение, оно не должно содержать лишнего. А в общем случае это не предусмотрено и собственно к БД отношения не имеет никакого. Это конкретная особенность конкретных СУБД. Как функции вывода на экран текста разных цветов -- где-то есть, но это не повод писать подобное в определении.

Ага, зрачки у персонажей такие, как будто уронили базу и осознали, что бэкап сделать не успели.

Ну вот зачем так? Когда статью смотрел особо не обращал внимания, а после вашего коммента только эти огромнейшие глаза и вижу. =)

А еще брови поверх волос.

Вот про текстовые файлики это вы зря. Физический формат хранения вполне может быть CSV, и это не перестанет быть базой данных. Базой набор файлов скорее делает наличие метаданных (что отлично демонстрирует скажем Hive).

Почему зря? Я же писала в статье, что такое тоже может быть)

Потому что мешанина из уровней абстракции

Когда-то в институте нам читали курс про эти самые базы данных. Это было ужасно и непонятно. Но, как и положено студентам, сдали и забыли. А через пару лет мне попалась книга про MS Access. И я был потрясен. Как же можно так непонятно, но наукообразно, объяснять такие простые вещи?

Так вот, переход от склада с коробками к плану выполнения запросов в oracle я тоже не понял, ЕВПОЧЯ.

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

Я не о том.

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

Это уже вторая такая статья автора у самого вопрос а зачем?

Это далеко не вторая статья автора из серии «Что такое...» :)
Внешний ключ нужен не «для связки двух таблиц в разных соотношениях», а лишь для ограничения целостности (в том числе для всяких каскадных удалений данных и т.п.). То есть связь-то можно сделать и без внешнего ключа, просто прописав в одной таблице id из другой. В таком случае тоже можно всякие join'ы без проблем делать, только не будет гарантий целостности. То есть не гарантируется то, что id, вписанные в поле таблицы, будут реально присутствовать в другой, но логическая связь между таблицами при этом есть же.

Вы сильно привязываетесб к реализации. Внешний ключ это просто внешний ключ. Как и первичный ключ. Это свойство отношения. Реалищация может быть самая разная. Например в MySQL по каждому ключу создается индекс а в PostgreSQL нет.

Я и не про его реализацию, а про то, что внешний ключ — это не связь, а ограничение целостности. Связь — это наличие идентификатора из одной таблицы в другой. Связь может быть и без внешнего ключа.
Внешний ключ — это вообще ПРАВИЛО. Правило контроля целостности и непротиворечивости данных, которое будет применяться соответствующей подсистемой СУБД. Кстати, кроме записи в структуре таблицы (и скорее всего в служебных системных таблицах — ну не бегать же каждый раз подсистеме контроля в таблицу за правилом), внешний ключ в БД вообще не имеет никакого физического воплощения.

А вот первичный ключ — это индекс. Вполне себе зримая штука в таблице, с конкретным физическим воплощением. К тому же это индекс, обременённый кучей ограничений, вроде запрета на NULL для любого поля, упомянутого в выражении первичного ключа, даже если этот NULL не приводит к NULL-значению выражения индекса. А в случае упомянутого MySQL, он ещё и кластерный.
>внешний ключ в БД вообще не имеет никакого физического воплощения.
На самом деле я бы разделял логическую модель (где нам все равно, какое там воплощение у некой сущности), и физическую, которая содержит определения, названия, типы и параметры скажем индексов, которые нашу логическую модель реализуют. Логически и первичный ключ может не иметь никакого воплощения — хотя обычно он да, индекс.

Но скажем в Hive за PK вполне может не быть ничего — потому что первичные ключи там игнорируются самой системой, а вот приложения уже могут читать метаданные, и проверять на уникальность, или делать что-то еще. Да, Hive вообще странная СУБД (или вообще не СУБД, хотя и имеет многие ее признаки) — но и такие существуют в природе.
Но скажем в Hive за PK вполне может не быть ничего — потому что первичные ключи там игнорируются самой системой,

Ну… вариант parsed but ignored — это случай, когда первичного ключа просто нет. И к фрагменту DDL, в котором описывается ПК, в данном случае отношение такое же, как к комментарию.
Не, почему? Если DDL приложению доступен — то приложение скажем может сделать distinct, прежде чем сохранить новые данные в таблицу. Ну то есть вариантов на самом деле два — игнорировать, и переложить на приложение.

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

Что это делает на хабре? Уже вторая статья уровня детский сад. Такие статьи делают хабр хуже. Я за бан автора.

Чем вам не угодили статьи для начального уровня? Если вы знаете предмет хорошо, то статья не для вас, просто не читайте.

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

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

Тем, что у автора много домыслов. Например,

Ключ можно поставить на любую колонку таблицы. Какую бы выбрать?

В то же самое время, в документациях мы читаем, что внешний ключ можно поставить только на primary key связываемой таблицы. Далее, автор предполагает, что foreign key можно поставить на группу колонок связываемой таблицы, но это не так. В документации по тому же PostgreSQL ясно читаем, что первичным ключом может быть группа колонок, которая ссылается на pk связываемой таблицы. То есть, всё наоборот. В то же время, есть понятие Потенциального Ключа таблицы, но Потенциальный Ключ - это для определения уникальности строки, а не для связывания. Опять же, выше писали абсолютно правильно, что foreign key обеспечивает не связь таблиц, а ограничение целостности. Далее, тот же постгрес автоматически создаёт индексы для уникальных значений и первичных ключей. Foreign Key, как мы помним, ссылается на pk. Отсюда следует, что выборка связанных объектов через foreign key, по дефолту производится через индекс (за исключением некоторых ситуаций).

Отсюда следует, что при подготовке материала автор не изучает документацию и не сверяет свои слова с тем, что описано в официальной теории. И вот, представь: джун читает на хабре: "foreign key может ссылаться на несколько столбцов". Он запоминает это, и уже вкачавшись до миддла носит в голове эту ересь. И ещё может ссылаться на неё: типа, нифига вы гоните - вот на хабре есть статья об этом.

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

Учитывая, что это не первая статья автора с её собственными домыслами, которые она выдаёт за факты, я поддерживаю мнение о необходимости бана автора. Нуили пусть она переписывает статьи, сверяя свои слова с авторитетными источниками.

вообще-то в postgres можно поставить foreign key на группу колонок и без primary key

так что перечитайте сами документацию

create table clients (
  name text,
  birthday date,
  unique(name, birthday)
);
  
  create table orders (
    name text,
    birthday date,
    
    foreign key (name, birthday) references clients(name, birthday)
 );
Ну, по содержанию замечание верное. А по сути — не совсем. Да, безусловно, fk может ставиться и на уникальные значения, но не на любой столбец, как указано у ТС. по группе тоже есть замечание:

www.postgresql.org/docs/11/ddl-constraints.html#DDL-CONSTRAINTS-FK

Of course, the number and type of the constrained columns need to match the number and type of the referenced columns.


Это мало меняет суть претензий к фразе

Ключ можно поставить на любую колонку таблицы. Какую бы выбрать?


А так, да, вы совершенно правы: связь с primary key идёт по-дефолту, что является синтаксическим сахаром и позволяет писать

create table clients (
  id integer primary key,
  name text,
  birthday date,
  unique(name, birthday)
);
  
  create table orders (
    client_id references clients
 );


вместо


  create table orders (
    client_id references clients(id)
 );
Я проконсультируюсь с разработчиками и потом вернусь с ответом или изменением в статье. (Пока исходно писала, тоже консультировалась с гуглом и людьми)
Вернулась) Можно ставить не только на «primary key», но и на уникальную колонку. Колонку можно обозвать уникальной любую, можно сделать связку колонок уникальными, а потом повесить на них FK.

То есть чисто технически при создании БД можно сказать «ФИО + ДР будут уникальными, вешаем на них ключ» (хотя это называется «выстрелить себе в ногу», но в жизни всякое бывает)

Про «какую бы выбрать» — ну так разработчик принимает решение, где хранятся уникальные данные. Или аналитик это делает за него. Не суть. Но это именно человек определяет, в какой колонке (или каких колонках) данные будут уникальными.

И что уж далеко ходить, пример с ФИО и ДР очень даже жизненный, можно погуглить статьи о том, как у людей деньги со счета списывали, потому что их тезка — должник. И потом начинаются суды с доказательством «да это не я был».

При этом судебные приставы приходят в банк с запросом «дай мне людей с такими то ФИО + ДР», а те не имеют права отказать, потому что это закон. Кстати, любопытно, изменилась ли ситуация за последние пару лет… Надеюсь, что да =)

В статью добавила слова об уникальности колонки для FK

Колонку можно обозвать уникальной любую

Таблица users, колонка patronymic - можно "обозвать" уникальной?

Таблица goods, колонка hex_color - можно "обозвать" уникальной?

Таблица orders, колонка price может быть уникальной?

И что уж далеко ходить, пример с ФИО и ДР очень даже жизненный, можно погуглить статьи о том, как у людей деньги со счета списывали, потому что их тезка — должник.

И вы своими статьями решили сделать эту ошибку повсеместной практикой?

А почему нельзя то? Что помешает при создании базы это сделать? Другой вопрос, насколько быстро мы огребем ошибку «данные неуникальны», но ведь это вообще никак не связано с возможностью выбрать колонку.

И вы своими статьями решили сделать эту ошибку повсеместной практикой?

Если человек прочитает мой пример до конца, он увидит, что вариант «ФИО + ДР уникальные» — плохой сценарий. И даже увидит хорошую альтернативу ему. Если он при этом решит, что всё же «это отличный сценарий для повсеместной практики», то это уже проблема не статьи
В статью добавила слова об уникальности колонки для FK

Тогда добавьте ещё и указание СУБД — вообще, или конкретно к этому факту. Ибо в общем случае оно неверно. См. напр. fiddle — внешний ключ в MySQL прекрасно работает и без всякой уникальности. Как я говорил в комментарии выше — внешний ключ есть правило. Правило, которое контролирует, что вставляемое/изменяемое в зависимой таблице значение присутствует в базовой. И ему глубоко плевать на уникальность.

Да, каскадные операции на нём дадут результат, далёкий от желаемого — но они и не обсуждаются.
Ну давайте теперь распишем один пример для всех СУБД… Сам пример про ключи вообще НИКАК не меняется от того, надо на колонку уникальность предварительно повесить или нет. Но ок, снова перефразировала слово «уникальной». Нет, конкретную СУБД я указывать не хочу, потому что повесить ключ можно в самых разных
Что это делает на хабре?


Нормальная статья. Далеко не все читатели хабра — универсалы и знают все обо всем.
И у каждого специалиста есть смежные с основной специальностью области, для которых нужны определенные знания. А получить их обычно некогда.
И тут помогает научно-популярный подход к теме.
Вы не обязаны понимать, «что тут вообще происходит» [речь идет о плане запроса], но вам нужно уметь получать этот план. Пригодится.

Никогда не понимал зачем в подобных статьях «для начинающих» закидывать абсолютно всё и сразу. Сначала «что такое БД», «как извлечь данные (select)» и в конце «хинты и план запроса»! Зачем? Тема хинтов и плана запроса очень сложные, по хорошему это отдельная добротная статья. Пример джоина таблиц clients и phone в демонстрации «плана запроса» тоже вызывает много вопросов, но повторюсь это можно обсуждать очень долго и наверное о таких вещах (хинты и план запроса) лучше вообще не писать в статьях «для начинающих».
В целом, до абзаца с «хинтами» статья вполне полезна начинающим.
Ну так если зайдет начало, то лучше сразу знать и про план, чтобы хотя бы знать что гуглить.
Видел «программистов», уложивших на лопатки сервер БД. Делать SELECT по какому-нибудь букварю вроде этого они выучились, а про план и оптимизацию/индексацию никогда не догадывались, в букваре этого не было.
Да, спасибо. В целом я тут согласна, что можно оставить на уровне «до этого момента, а не всё и сразу». Просто делать несколько коротких статей — ну точно не для Хабра. А у новичков (по крайней мере тестировщиков) иногда спрашивают именно общее понимание «что такое план / статистика», поэтому решила оставить

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

Но зачем пересказывать статью из Википедии, если статья в Википедии уже есть?

Хотела сказать, что это не в заголовке, а в первых абзацах написано, но не написано. Спасибо, исправила :)
Тема индексов в таблице не раскрыта. Общая концепция ясна, но без конкретных примеров не очень понятно как применять её на практике. Понимаю, что эта статья должна стать лишь отправной точкой (чем для меня и стала), но с отсутствующим примером, статья ощущается не полной.
За проделанную работу и оставленные ссылки спасибо. Изложено предельно просто и доходчиво.
Спасибо) Если подкинете хороший ссылки для раскрытия тем, обязательно добавлю в статью ^_^
Главное — не валите все в одну кучу. Вы тут пытались упомянуть оптимизацию, так я как-то недавно писал пост на тему, какие они вообще бывают, виды оптимизаций. И там далеко не все описано, что бывает — куча видов индексов вообще не затронута, например. Т.е. условно — только это тема для поста минимум. А полноценно — для книги. А чтобы впихнуть это в пару абзацев…

Да и планы скажем — чтобы понимать, что такое вообще план, нужно понимать, как вообще выполняется та или иная операция в СУБД. Скажем, сортировка… вы очевидно можете отсортировать таблицу при выполнении запроса — а можете выбрать нужные данные из индекса, если у вас уже есть подходящий индекс, уже отсортированный в нужном порядке (и в нем есть все нужные вам колонки).

Или JOIN — его можно выполнять несколькими принципиально разными способами. И если человек не знает этих способов, их преимущества и недостатки (разные в зависимости от свойств наших данных) — ему ничем не поможет тот факт, что он сумел набрать команду EXPLAIN. Ну узнал он, что вот там HASH JOIN, ему сильно полегчало?
Спасибо, ссылку на вашу статью добавила.

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

Реально достал уже этот детсад. Поставил минус посту. Открываешь почитать тематическую ленту после тяжёлого трудового дня, и видишь этот бред с картинками. Люди с цветными линзами от телескопа вместо глаз.

Я так и не понял для кого эта статья? Для школьников? Для гламурных девочек? Перебарщиваете с картинками, и со стилем текста "для самых маленьких".. не надо так.

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

Отличная статья, огромное спасибо автору! С нетерпением ждем статью "что такое компьютер"!

Только в статье должны обязательно быть:

  • Комиксы

  • Занимательные факты из биографии Билла Гейтса

  • Простыня какого-то кода

Чтобы стиль сохранялся ;)

Тут нужен цикл статей: "Как включить компьютер?", "Что такое компьютерная мышь?" и т.д.

Вот и пришло время, когда на Хабре котируются статьи уровня "БД для чайников"?

Снимаю шляпу! Спасибо! Очень просто, можно советовать любому начинающему вникать в "что есть бд и с чем её едят".

Если поэтапно разбить:

1) серверная часть на ПК (к примеру, express выпуски, freeware,...)

2) серверная часть на сервере (standart, условно-бесплатные, enterprise,...)

3) клиентская часть на ПК(express,lite, ...)

4) клиентская часть на мобильных устройствах (...)

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

Ну и постараться не использовать слова типа "винде", грубовато не кажется? Хотя молодежь поймёт лучше (мягче чем Windows).

Да, понимаю,что цель статьи не писать книгу, а просто сделать заметку, которую легко скинуть ребёнку. Но всё же, с детства, считаю более правильным приучать к бумажной литературе, и только потом, позже... А что я пишу, всё равно обойдут "ограничения")))

Спасибо!

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

Веб-сайт работает на основе базы данных. В базе хранятся нормализованные данные, словари, индексы. База поддерживает требования ACID. База находится в одном файле MS Access и подключается через ODBC.

Какие недостатки у этого решения? Когда и зачем надо переходить на другую СУБД?

Спасибо.
Ничего себе у вас «простые» вопросы! :) Я не знаю ответ

Какие недостатки у этого решения? Когда и зачем надо переходить на другую СУБД?

На эти вопросы тестировщик не должен знать ответ.

Мы видим, что в первой комнате живет котик с id = 1, а во второй — с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.

А по таблице в первой комнате живет кот с идентификатором 11.
Хм. Пересмотрела пример, не нашла там кота с id=11
«Я ничего не понимаю в БД. Но я всё-таки расскажу то, как я понимаю.»

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

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

С «забудьте всё» не согласна, эта статья даёт общее понятие о том, что такое база, зачем в ней индексы, как может помочь статистика, итд. Что отсюда надо забыть для реальной практики? У меня этой практики около 6 лет, да, не на уровне DBA или разработчика, но про «кому в первую очередь предназначена статья», я уже внесла в самое начало
И выясняется, что и на ноль делить можно

Вас обманули. На самом деле на ноль делить нельзя.

В поле (или теле) нельзя определить такую бинарную функцию, обратную к умножению (a : b = d(a,b) <=> d(a,b)*b = a), чтобы в её область определения входил 0 по второму аргументу:

  1. Для любого a != 0, d(a,0)*0 = a, но с другой стороны d(a,0)*0 = 0, т.е. a=0 - противоречие

  2. А d(0,0)*0 = 0 - подходит любое число, т.е. не получится сделать функцией

Т.е. рассказывать про "Базы данных для малышей" надо обязательно на примере одной из самых люто-коммерческих энтерпрайзных БД Oracle?

А почему бы и нет? Что такого изменится сильно в другой реляционной базе? Внешний вид интерфейса разве что, но тут из интерфейса пара картинок всего

Что такого изменится сильно в другой реляционной базе?

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

Раздел «что такое БД» от этого не меняется, а дальше написано, что примеры именно про реляционные и почему.

Ну а так как статья не про SQL, и запросов «бери и повторяй» в ней нет, не вижу принципиальной разницы. И лучше рассказать о том, с чем работаешь, чтобы не наделать ещё больше ляпов)
Автор явно не различает БД и СУБД
За рассказ про хинты в статье для «начинающих» отдельный огромный дизреспект. Вот начитаются таких статей, и потом начинают гуглить самые популярные хинты и куда их вставлять.
Тем более что далее идет рассказ по большей части не про хинты а про план выполнения — и это действительно может быть полезно для тестировщиков в плане «как посмотреть план, сохранить его и отправить разработчикам», но, в основном, для тестировщиков, работающих с одной конкретной СУБД с помощью одного конкретного приложения.
В общем и целом, статья требует огромной редакторской работы от нормального разработчика БД, очень много что требует правок, в текущем виде я даже не знаю, чего больше — пользы или вреда. Наверное, все таки пользы для совсем уж новичков, но жалко, что не сделан тот небольшой, но важный вклад от профессионала, который позволил бы избежать таких явных ошибок.
Возможно, вы правы, и именно хинты можно убрать вообще от слова совсем. На собеседованиях обычно спрашивают про индексы или статистику, на уровне понимания, что это такое. Но именно из-за этого блок про ускорение убирать совсем не хочется
Впрочем, можно назвать этот пункт «Что делать, если запросы тормозят» и оставить там только инфу для тестировщиков о том, что вот есть статистика и можно собрать план и отдать разработчикам. Так будет лучше? :)

Про хинты и индексы я тогда в блог просто вынесу отдельно, на индексы отсылку где-то дам, потому что это полезно для понимания именно новичку.
Про статистику и планы в целом ок, индексы создавать в целом не задача тестировщика, но понимание будет полезным и если он сможет увидеть на плане отсутствие нужного индекса — это тоже полезные умения, так что да, в таком виде будет лучше, наверное.
Переписала разделы:
  • Зачем в базе индексы
  • Что делать, если запрос к БД тормозит

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

Ну и небольшое пожелание по индексам (раз уж перечитал их):
Совсем другое дело, если книги отсортированы по авторам. А внутри автора — по названию.

Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!

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

Что делать, если запросы тормозят

Жаловаться специалисту, очевидно же. Желательно тому, кто прослушал курсы DBA от этого самого oracle ;)

Это верно! Но задача тестировщика — жаловаться грамотно, то есть с предоставлением всей нужной информации =)

Не троллинга окаянного ради, но подвести черту для ;)

Картинки хороши. Это плюс.

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

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

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

Кто мой читатель, написано в первых абзацах. Хабр прекрасно гуглится, а запросов от новичков поступает много, ведь их больше, чем опытных коллег. Почему бы не дать им понятное объяснение на уровне «что это такое»
Сорри, я просто сломался на 4 картинке ;) Посыпаю голову пепелом, дальше картинки лучше ;) Но, согласитесь, без них информация из статьи не станет менее понятной ;)
можно было идею с коробками пронести через всю статью

Я этого не предлагал ;) Но коробка как визуальное представление блока данных — это весьма наглядно.

Почему бы не дать им понятное объяснение на уровне «что это такое»


Могу порекомендовать книгу «Access для чайников» (гуглится, пиратится), глава про основы баз данных. Всё разложено по полочкам, коротко и понятно.
www.sql-ex.ru — Бесплатный тренажер для практики

Солидарна с автором! С помощью данного тренажера отточила практически навыки sql-запросов.
Что я могу сказать. Прочитав статью, я лишь подтвердил что в ближайшее время кризис на рынке it специалистов, в ближайшее время, не решится.

Это не материал для обучения специалистов, это материал для их убийства.

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


У автора также проблемы с пониманием СУБД — БД. Из-за чего по тексту так-же возникают фундаментальные ошибки.

=====
База данных — это место для хранения данных.

Неверно. База данных — это место для хранения структурированных данных.
Если говорить аналогиями, то мешок — это не БД, а шкаф с полками — вполне себе. Только лишь потому что в шкафу с полками, можно структурировать содержимое.
Отсутствие одного слова сразу ломает все понимание сущности БД, что не дает на его основе делать правильные самостоятельные выводы.
Используется в клиент-серверной архитектуре

Клиент-серверная архитектура при использовании БД — это лишь частный случай. Это утверждение сразу зарезает понимание того что БД можно использовать и в других случаях. Например:
[ Клиент ] => [ СУБД ] => [ БД ]
[ Клиент [ СУБД ] ] => [ БД ]

и чем она лучше хранения информации в простых текстовых файликах

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

Мы еще до содержания не дошли, а у читателя уже фундаментальные ошибки в понимании что такое БД и как оно используется.

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

Утверждение порождающее больше вопросов чем ответов. Если приложение небольшое — это значит что БД ей совсем не нужна? Или нужна в составе самого приложения? Но ведь БД, по предыдущим определениям, не может быть кроме как за бэкендом. Что такое отдельная БД? Насколько небольшим должно быть приложение? Размер приложения — это размер билда или объем хранимых данных?
Автор только что привязала наличие БД и его местоположение к размеру приложения. Что фундаментально неверно. Большинство приложений имеет БД в том или ином виде. Объем хранимых данных на одного пользователя в большинстве случаев не превышает объем памяти устройства на котором находится приложение. Внешнее БД используется в основном для агрегации, централизованного доступа к данным, их синхронизации и обработке.

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

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

Да примерно как excel-табличка

Очень притянуто за уши и только как частный случай.

Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.

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

Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта

Пляска на гробу. Автор тут утверждает что MongoDB — не реляционная БД потому что она хранит объекты виде объектов, а не таблиц.
Таблица — представление данных. Данные из Mongo можно также представить в виде таблицы. Как и данные из MySql представить в виде объектов.

А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!

Тут у читателя происходит когнитивный диссонанс.

моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели.

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

Дальше автор приводит некоторые примеры для работы с SQL. В принципе норм.
Но тут на сцену влетает foreign key!
Во первых: начинающему эта информация будет несколько сложноватой. особенно с абсолютным непониманием что такое реляционная БД.
Во вторых: foreign key по дальнейшим примерам создается, но не используется. Объяснения зачем он нужен нет.

Индексы. По тексту получается, что они сортируют данные в таблице. Часто встречал такое представление у «специалистов». Видимо тоже учились по таким материалам.

Преимущества базы данных

Каких и в сравнении с какими?
Почему используют базу, а не сохраняют данные в файликах?

БД тоже находятся в файликах
Может автор имела ввиду СУБД?
Базы поддерживают требования ACID (по крайней мере транзакционные БД)

Т.е все таки показываются преимущества именно транзакционных СУБД?
Это единый синтаксис SQL, который используется повсеместно

Еще и реляционных

Так может вывести в заголовок «Преимущества транзакционных SQL СУБД»?
Потому что эти пункты никак не относятся к преимуществам использования самих БД

=====

Автор совсем не разбирается в вопросе который она подняла. А конкретно: что такое БД. Не говоря уж о том что такое СУБД. Для чего они нужны и как их используют.
Видимо для ее квалификации на той должности на которой она находится большего и не надо.
Но чтобы не стать очередным некомпетентным «специалистом», которыми весь IT рынок завален, такие статьи обходить стороной.

=====

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

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

Это утверждение сразу зарезает понимание того что БД можно использовать и в других случаях.

Не зарезает, но может и так трактоваться, добавила фразу «в том числе»

Автор этим утверждением противоречит сама себе, как собственному определению БД, так и дальнейшим утверждением что существуют БД, использующие текстовые файлы.


Но ведь «БД, используящая файлы» ≠ «просто любые файлы».

Утверждение порождающее больше вопросов чем ответов.

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

Очень притянуто за уши и только как частный случай.

Там тут же сказано, что это реляционная база

Объяснения зачем он нужен нет.

Есть, для связи таблиц

Так может вывести в заголовок «Преимущества транзакционных SQL СУБД»?

Вывела «реляционных»)

Какие выводы я сделал. Пока существуют такие материалы, стоимость меня как специалиста будет только расти.

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

Я и не говорил, что нельзя. Но полки дают возможность структурировать данные. В отличии от их отсутствия.
Но ведь «БД, используящая файлы» ≠ «просто любые файлы».

Вы же опять себе же и противоречите. Нет особых файлов в которых находятся БД. Давайте посмотрим определение БД: «Хранилище структурированных данных». Всё. Тут нет ни слова о виде хранилища. Память, файлы, магнитная лента… перфокарты… Так что да, любой файл содержащий структурированные данные — БД. В том числе и «простые текстовые файлики».
А у новичка это утверждение все эти вопросы не вызовет, а для понимания вполне понятно.

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

Это не объяснение. Что за связи? Зачем? Что будет, когда новичку дадут отлично функционирующую реляционную БД без единого foreign key? Почему вы думаете что на собеседовании не спросят что такое связи, зачем они нужны, и можно ли без них обойтись?
А начинающая статья никогда не сделает человека специалистом.

Никогда. Зато всегда может помешать в адекватном восприятии дальнейшей информации.
Так что да, любой файл содержащий структурированные данные — БД.

Не могу спорить с этим утверждением, так как файловые БД в глаза не видела. Впрочем, из начала статьи про «чем это лучше простого файлика» я убрала ещё в прошлый раз.

Как написано, так и запомнит.

Ну так пусть запомнит. Это примерно как сказать, что для простого проекта VCS не нужна. Или что для простого SVN хватит. Можно и тут докопаться и задать кучу вопросов. Можно сразу уйти в дебри пояснений, какое приложение маленькое и прочая-прочая. Но новичку это не нужно. Ему нужно понимание в целом, что можно обойтись и без этого, но с ростом объемов будет сложно. И весь пример с магазинчиком — про это. А дальше уже перекладываешь его в область ИТ.

Это не объяснение.

Ну тут уж извините. Кто-то понял, кто-то нет. Кто не понял, пойдет искать другую статью, где будет описано понятнее. В статье идет большой пример про варианты хранения и необходимость ссылки на другие таблицы. Как эта отсылка делается — вот. Чтобы понять, ЗАЧЕМ этот ключ вообще нужен — этого хватает. Если надо копать глубже — это выходит за рамки этой статьи.

Зато всегда может помешать в адекватном восприятии дальнейшей информации.

Ошибки в статьях я исправляю. Но не «мне не нравятся картинки, это какой-то детский сад», «вот тут можно объяснить подробнее, а там рассказать сильно больше». Понимание статья даёт, а уж на уровне начинающего тестировщика — за глаза. А вот неадекватно воспринимать информацию можно всегда, даже с тщательно расписанной статьей, которая каждую тему раскрывает глубоко (тем более что в такой статье легче запутаться)
Only those users with full accounts are able to leave comments. Log in, please.