Комментарии 102
Картинки в статье шикарные !
DIXI
На вкус и на цвет.. дыры в голове вместо глаз и общий уровень объяснений "детсад, группа \"Кроха\"".. Барсик, 5 лет, id:3. Никак не понять без картинки, а с картинкой сразу предельно ясно становится.
OMG
Настины комиксы. Не надо так (ц)
Да если бы вопрос был только в стилистике… тут в погоне за гламурностью ещё и смысл теряется, иногда — полностью.
Берём картинку, которая в статье аж два раза — в начале и в конце:
В БД лежат данные приложения...
Какого ещё приложения? Нет у меня никакого приложения, а данные и БД — есть. Смысл сводится к "в базе данных лежат данные"? Отлично, очень ценный постулат, а то мы сомневались, может, там дрова лежат. Здесь бы написать, что делает кучу данных базой, ан нет: главное — гламур.
Она обеспечивает их сохранность ...
Сохранность обеспечивает хороший бэкап. А здесь явно не про сценарии с репликацией. В общем случае — нет, не обеспечивает.
… и позволяет легко и быстро по ним искать.
В общем случае — нет, не позволяет, или не легко, или не быстро. Поиск по данным не является неотъемлемым свойством БД.
Получается, что на заглавной картинке написана чепуха, а этого никто не замечает? Да, именно так, потому что гламур и "звёздные дыры" отвлекают внимание. И именно поэтому не надо знания превращать в комикс, фигня получается.
Например, дальше про foreign key и primary index — просто ерунда написана, такая "околоправда", которая выглядит натурально и способна задурить мозги новичкам, но на деле — чушь.
Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество.
Что? Как, а главное — зачем??
А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ.
Ооо, мой мозг! В "внешний ключ" и "первичный ключ" только слово "ключ" одинаковые, а так они вообще разные и для разного — кому вообще пришло в голову пытаться заменить одно другим?
… но я же ставила foreign key на ФИО + ДР...
Что за "foreign key на ФИО + ДР"? объясните, где такое вообще возможно?
Ага, вы связаны. Значит, в orders всегда есть ссылка на clients
Нет, конечно. Там вполне может оказаться NULL, зависит от CONSTRAINT.
В общем, количество чуши прямо пропорционально количеству гламура. А возможно, зависимость даже нелинейная.
Было бы неплохо аргументировать..
СУБД может эти заниматься, но совершенно не обязана. SQLite, например, очень даже СУБД. А так -- можно и Clarion взять в качестве образца СУБД, и ещё кучу фич запихнуть в определение.
Если даётся общее определение, оно не должно содержать лишнего. А в общем случае это не предусмотрено и собственно к БД отношения не имеет никакого. Это конкретная особенность конкретных СУБД. Как функции вывода на экран текста разных цветов -- где-то есть, но это не повод писать подобное в определении.
Согласен с вами - глаз радует!
Вот про текстовые файлики это вы зря. Физический формат хранения вполне может быть CSV, и это не перестанет быть базой данных. Базой набор файлов скорее делает наличие метаданных (что отлично демонстрирует скажем Hive).
Когда-то в институте нам читали курс про эти самые базы данных. Это было ужасно и непонятно. Но, как и положено студентам, сдали и забыли. А через пару лет мне попалась книга про MS Access. И я был потрясен. Как же можно так непонятно, но наукообразно, объяснять такие простые вещи?
Так вот, переход от склада с коробками к плану выполнения запросов в oracle я тоже не понял, ЕВПОЧЯ.
Это вы еще не сдушали курс дискретной математики где это все объятснаялоь с терминах полное функциональное отношения и т.п.
Вы сильно привязываетесб к реализации. Внешний ключ это просто внешний ключ. Как и первичный ключ. Это свойство отношения. Реалищация может быть самая разная. Например в MySQL по каждому ключу создается индекс а в PostgreSQL нет.
А вот первичный ключ — это индекс. Вполне себе зримая штука в таблице, с конкретным физическим воплощением. К тому же это индекс, обременённый кучей ограничений, вроде запрета на NULL для любого поля, упомянутого в выражении первичного ключа, даже если этот NULL не приводит к NULL-значению выражения индекса. А в случае упомянутого MySQL, он ещё и кластерный.
На самом деле я бы разделял логическую модель (где нам все равно, какое там воплощение у некой сущности), и физическую, которая содержит определения, названия, типы и параметры скажем индексов, которые нашу логическую модель реализуют. Логически и первичный ключ может не иметь никакого воплощения — хотя обычно он да, индекс.
Но скажем в Hive за PK вполне может не быть ничего — потому что первичные ключи там игнорируются самой системой, а вот приложения уже могут читать метаданные, и проверять на уникальность, или делать что-то еще. Да, Hive вообще странная СУБД (или вообще не СУБД, хотя и имеет многие ее признаки) — но и такие существуют в природе.
Только не целостности, а связности. Это просто выносит логику связи между таблицами на уровень базы данных.
Чем вам не угодили статьи для начального уровня? Если вы знаете предмет хорошо, то статья не для вас, просто не читайте.
Но это как статьи про мурзилку и его приключения публиковать, это же бред.
Тем, что у автора много домыслов. Например,
Ключ можно поставить на любую колонку таблицы. Какую бы выбрать?
В то же самое время, в документациях мы читаем, что внешний ключ можно поставить только на primary key связываемой таблицы. Далее, автор предполагает, что foreign key можно поставить на группу колонок связываемой таблицы, но это не так. В документации по тому же PostgreSQL ясно читаем, что первичным ключом может быть группа колонок, которая ссылается на pk связываемой таблицы. То есть, всё наоборот. В то же время, есть понятие Потенциального Ключа таблицы, но Потенциальный Ключ - это для определения уникальности строки, а не для связывания. Опять же, выше писали абсолютно правильно, что foreign key обеспечивает не связь таблиц, а ограничение целостности. Далее, тот же постгрес автоматически создаёт индексы для уникальных значений и первичных ключей. Foreign Key, как мы помним, ссылается на pk. Отсюда следует, что выборка связанных объектов через foreign key, по дефолту производится через индекс (за исключением некоторых ситуаций).
Отсюда следует, что при подготовке материала автор не изучает документацию и не сверяет свои слова с тем, что описано в официальной теории. И вот, представь: джун читает на хабре: "foreign 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)
);
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)
);То есть чисто технически при создании БД можно сказать «ФИО + ДР будут уникальными, вешаем на них ключ» (хотя это называется «выстрелить себе в ногу», но в жизни всякое бывает)
Про «какую бы выбрать» — ну так разработчик принимает решение, где хранятся уникальные данные. Или аналитик это делает за него. Не суть. Но это именно человек определяет, в какой колонке (или каких колонках) данные будут уникальными.
И что уж далеко ходить, пример с ФИО и ДР очень даже жизненный, можно погуглить статьи о том, как у людей деньги со счета списывали, потому что их тезка — должник. И потом начинаются суды с доказательством «да это не я был».
При этом судебные приставы приходят в банк с запросом «дай мне людей с такими то ФИО + ДР», а те не имеют права отказать, потому что это закон. Кстати, любопытно, изменилась ли ситуация за последние пару лет… Надеюсь, что да =)
В статью добавила слова об уникальности колонки для FK
Колонку можно обозвать уникальной любую
Таблица users, колонка patronymic - можно "обозвать" уникальной?
Таблица goods, колонка hex_color - можно "обозвать" уникальной?
Таблица orders, колонка price может быть уникальной?
И что уж далеко ходить, пример с ФИО и ДР очень даже жизненный, можно погуглить статьи о том, как у людей деньги со счета списывали, потому что их тезка — должник.
И вы своими статьями решили сделать эту ошибку повсеместной практикой?
И вы своими статьями решили сделать эту ошибку повсеместной практикой?
Если человек прочитает мой пример до конца, он увидит, что вариант «ФИО + ДР уникальные» — плохой сценарий. И даже увидит хорошую альтернативу ему. Если он при этом решит, что всё же «это отличный сценарий для повсеместной практики», то это уже проблема не статьи
В статью добавила слова об уникальности колонки для FK
Тогда добавьте ещё и указание СУБД — вообще, или конкретно к этому факту. Ибо в общем случае оно неверно. См. напр. fiddle — внешний ключ в MySQL прекрасно работает и без всякой уникальности. Как я говорил в комментарии выше — внешний ключ есть правило. Правило, которое контролирует, что вставляемое/изменяемое в зависимой таблице значение присутствует в базовой. И ему глубоко плевать на уникальность.
Да, каскадные операции на нём дадут результат, далёкий от желаемого — но они и не обсуждаются.
Что это делает на хабре?
Нормальная статья. Далеко не все читатели хабра — универсалы и знают все обо всем.
И у каждого специалиста есть смежные с основной специальностью области, для которых нужны определенные знания. А получить их обычно некогда.
И тут помогает научно-популярный подход к теме.
Вы не обязаны понимать, «что тут вообще происходит» [речь идет о плане запроса], но вам нужно уметь получать этот план. Пригодится.
Никогда не понимал зачем в подобных статьях «для начинающих» закидывать абсолютно всё и сразу. Сначала «что такое БД», «как извлечь данные (select)» и в конце «хинты и план запроса»! Зачем? Тема хинтов и плана запроса очень сложные, по хорошему это отдельная добротная статья. Пример джоина таблиц clients и phone в демонстрации «плана запроса» тоже вызывает много вопросов, но повторюсь это можно обсуждать очень долго и наверное о таких вещах (хинты и план запроса) лучше вообще не писать в статьях «для начинающих».
В целом, до абзаца с «хинтами» статья вполне полезна начинающим.
Если бы в заголовке было написано "Что такое база данных с точки зрения новичка - тестировщика" - многих вопросов не возникло бы. Новичок-тестировщик узнал, что существуют базы данных и написал статью, прошу понять и простить. Но можно же хотя бы статью из Википедии пересказать, там информация хотя бы систематизирована.
За проделанную работу и оставленные ссылки спасибо. Изложено предельно просто и доходчиво.
Да и планы скажем — чтобы понимать, что такое вообще план, нужно понимать, как вообще выполняется та или иная операция в СУБД. Скажем, сортировка… вы очевидно можете отсортировать таблицу при выполнении запроса — а можете выбрать нужные данные из индекса, если у вас уже есть подходящий индекс, уже отсортированный в нужном порядке (и в нем есть все нужные вам колонки).
Или JOIN — его можно выполнять несколькими принципиально разными способами. И если человек не знает этих способов, их преимущества и недостатки (разные в зависимости от свойств наших данных) — ему ничем не поможет тот факт, что он сумел набрать команду EXPLAIN. Ну узнал он, что вот там HASH JOIN, ему сильно полегчало?
Реально достал уже этот детсад. Поставил минус посту. Открываешь почитать тематическую ленту после тяжёлого трудового дня, и видишь этот бред с картинками. Люди с цветными линзами от телескопа вместо глаз.
Я так и не понял для кого эта статья? Для школьников? Для гламурных девочек? Перебарщиваете с картинками, и со стилем текста "для самых маленьких".. не надо так.
После текста для самых маленьких сразу идет упоминание хинтов, индексов, и прочего что не нужно в рамках этой статьи. Еще и с кучей ошибок.
Отличная статья, огромное спасибо автору! С нетерпением ждем статью "что такое компьютер"!
Вот и пришло время, когда на Хабре котируются статьи уровня "БД для чайников"?
Снимаю шляпу! Спасибо! Очень просто, можно советовать любому начинающему вникать в "что есть бд и с чем её едят".
Если поэтапно разбить:
1) серверная часть на ПК (к примеру, express выпуски, freeware,...)
2) серверная часть на сервере (standart, условно-бесплатные, enterprise,...)
3) клиентская часть на ПК(express,lite, ...)
4) клиентская часть на мобильных устройствах (...)
Можно прямо книгу выпускать для детей. Просто взрослым понятно, где клиентская часть, для чего она нужна, где "основная" база и зачем она нужна. Попробовать расписать почему одна база "в поле не воин"(пока без кластеров, тяжело слишком будет), прочее)
Ну и постараться не использовать слова типа "винде", грубовато не кажется? Хотя молодежь поймёт лучше (мягче чем Windows).
Да, понимаю,что цель статьи не писать книгу, а просто сделать заметку, которую легко скинуть ребёнку. Но всё же, с детства, считаю более правильным приучать к бумажной литературе, и только потом, позже... А что я пишу, всё равно обойдут "ограничения")))
Спасибо!
Веб-сайт работает на основе базы данных. В базе хранятся нормализованные данные, словари, индексы. База поддерживает требования ACID. База находится в одном файле MS Access и подключается через ODBC.
Какие недостатки у этого решения? Когда и зачем надо переходить на другую СУБД?
Спасибо.
Мы видим, что в первой комнате живет котик с id = 1, а во второй — с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.
А по таблице в первой комнате живет кот с идентификатором 11.
Это ужасно. Уважаемый автор, ради всего святого, не пишите больше подобных вещей — или хотя бы найдите тех, кто реально эксперт в данной области, отдайте им на рецензирование свой труд, и публикуйте только тогда, когда хотя бы одна рецензия будет положительной.
Сейчас это труд из разряда «запомните, дети — на ноль делить нельзя». Потому что как только столкнёшься с практикой, так «а теперь, дети, забудьте всё то, что вам говорили раньше». И выясняется, что и на ноль делить можно, и корень квадратный из минус единицы извлекать, и вообще…
С «забудьте всё» не согласна, эта статья даёт общее понятие о том, что такое база, зачем в ней индексы, как может помочь статистика, итд. Что отсюда надо забыть для реальной практики? У меня этой практики около 6 лет, да, не на уровне DBA или разработчика, но про «кому в первую очередь предназначена статья», я уже внесла в самое начало
И выясняется, что и на ноль делить можно
Вас обманули. На самом деле на ноль делить нельзя.
Почему?
В поле (или теле) нельзя определить такую бинарную функцию, обратную к умножению (a : b = d(a,b) <=> d(a,b)*b = a), чтобы в её область определения входил 0 по второму аргументу:
Для любого a != 0, d(a,0)*0 = a, но с другой стороны d(a,0)*0 = 0, т.е. a=0 - противоречие
А d(0,0)*0 = 0 - подходит любое число, т.е. не получится сделать функцией
Т.е. рассказывать про "Базы данных для малышей" надо обязательно на примере одной из самых люто-коммерческих энтерпрайзных БД Oracle?
Тем более что далее идет рассказ по большей части не про хинты а про план выполнения — и это действительно может быть полезно для тестировщиков в плане «как посмотреть план, сохранить его и отправить разработчикам», но, в основном, для тестировщиков, работающих с одной конкретной СУБД с помощью одного конкретного приложения.
В общем и целом, статья требует огромной редакторской работы от нормального разработчика БД, очень много что требует правок, в текущем виде я даже не знаю, чего больше — пользы или вреда. Наверное, все таки пользы для совсем уж новичков, но жалко, что не сделан тот небольшой, но важный вклад от профессионала, который позволил бы избежать таких явных ошибок.
Про хинты и индексы я тогда в блог просто вынесу отдельно, на индексы отсылку где-то дам, потому что это полезно для понимания именно новичку.
- Зачем в базе индексы
- Что делать, если запрос к БД тормозит
Посмотрите, пожалуйста, так лучше? :)
Ну и небольшое пожелание по индексам (раз уж перечитал их):
Совсем другое дело, если книги отсортированы по авторам. А внутри автора — по названию.
Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!
Вот тут у вас пример про многоколоночный индекс, а вывод — про одноколоночный. Можно расширить вывод, что индекс можно повесить на несколько нужных колонок (только есть ограничения в размерах, но это уже тонкости), главное — не забывать порядок поиска в индексе. Если у нас индекс сначала по автору а потом по названию, то если нам нужно найти книгу по названию — такой индекс нам будет бесполезен и придется все равно пересматривать все книги, поэтому, если нам часто нужно искать по названию и почти никогда — только по автору, имеет смысл поменять порядок в индексе — сначала название, потом автор.
Что делать, если запросы тормозят
Жаловаться специалисту, очевидно же. Желательно тому, кто прослушал курсы DBA от этого самого oracle ;)
Не троллинга окаянного ради, но подвести черту для ;)
Картинки хороши. Это плюс.
Картинки совершенно не связаны с текстом. Это минус. Не надо так. Ведь этот ваш склад с коробками - готовая абстракция и для таблиц, и ключей, и даже для индексов; почему вы не оформили это графически - непонятно.
Текст никакой. Рифма вроде есть, смысла вроде нет. Куча разрозненных представлений, как-то связанных с базами данных. Кому это может быть интересно и полезно? Кто ваш читатель? Это точно для хабра?
Кто мой читатель, написано в первых абзацах. Хабр прекрасно гуглится, а запросов от новичков поступает много, ведь их больше, чем опытных коллег. Почему бы не дать им понятное объяснение на уровне «что это такое»
можно было идею с коробками пронести через всю статью
Я этого не предлагал ;) Но коробка как визуальное представление блока данных — это весьма наглядно.
Почему бы не дать им понятное объяснение на уровне «что это такое»
Могу порекомендовать книгу «Access для чайников» (гуглится, пиратится), глава про основы баз данных. Всё разложено по полочкам, коротко и понятно.
www.sql-ex.ru — Бесплатный тренажер для практики
Солидарна с автором! С помощью данного тренажера отточила практически навыки sql-запросов.
Это не материал для обучения специалистов, это материал для их убийства.
При таком подходе к предоставлению информации может и даст человеку набор тезисов, но действительного понимания не дает абсолютно. Хотя автор утверждает что статья направлена на
общее понимание «а что это вообще такое»
У автора также проблемы с пониманием СУБД — БД. Из-за чего по тексту так-же возникают фундаментальные ошибки.
=====
База данных — это место для хранения данных.
Неверно. База данных — это место для хранения структурированных данных.
Если говорить аналогиями, то мешок — это не БД, а шкаф с полками — вполне себе. Только лишь потому что в шкафу с полками, можно структурировать содержимое.
Отсутствие одного слова сразу ломает все понимание сущности БД, что не дает на его основе делать правильные самостоятельные выводы.
Используется в клиент-серверной архитектуре
Клиент-серверная архитектура при использовании БД — это лишь частный случай. Это утверждение сразу зарезает понимание того что БД можно использовать и в других случаях. Например:
[ Клиент ] => [ СУБД ] => [ БД ]
[ Клиент [ СУБД ] ] => [ БД ]
и чем она лучше хранения информации в простых текстовых файликах
Из этого утверждения можно сделать неверный вывод, что текстовые файлики не могут выступать в роли БД.
Автор этим утверждением противоречит сама себе, как собственному определению БД, так и дальнейшим утверждением что существуют БД, использующие текстовые файлы.
Мы еще до содержания не дошли, а у читателя уже фундаментальные ошибки в понимании что такое БД и как оно используется.
Если приложение небольшое, отдельная база не нужна. Но потом это становится удобнее и выгоднее с точки зрения памяти.
Утверждение порождающее больше вопросов чем ответов. Если приложение небольшое — это значит что БД ей совсем не нужна? Или нужна в составе самого приложения? Но ведь БД, по предыдущим определениям, не может быть кроме как за бэкендом. Что такое отдельная БД? Насколько небольшим должно быть приложение? Размер приложения — это размер билда или объем хранимых данных?
Автор только что привязала наличие БД и его местоположение к размеру приложения. Что фундаментально неверно. Большинство приложений имеет БД в том или ином виде. Объем хранимых данных на одного пользователя в большинстве случаев не превышает объем памяти устройства на котором находится приложение. Внешнее БД используется в основном для агрегации, централизованного доступа к данным, их синхронизации и обработке.
Тоже самое и в приложениях. Если приложение маленькое, то все данные можно хранить в памяти. Но учтите, что это память на вашем компьютере, вашем телефоне. И чем больше данных туда пихать, тем медленнее будет работать программа.
Место в памяти ограничено. Поэтому когда данных много, их нужно куда-то сложить. Можно писать в файлики, а можно сохранять информацию в базу данных (сокращенно БД). Выбор за вами. А точнее, за вашим разработчиком.
Эти абзацы следуют из предыдущих и только усугубляют проблему. Ведь БД тоже занимает место. Конечно автор этими словами хочет обосновать свою позицию в использовании БД как внешний сервис в клиент-серверной архитектуре. Но это никак не связано с пониманием того для чего вообще БД используется.
Да примерно как excel-табличка
Очень притянуто за уши и только как частный случай.
Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.
Автор дальше пытается уничтожить вообще любое понимание что такое БД. С этим определением реляционными можно назвать и документные БД. Автор абсолютно не понимает что значит реляционные, хотя дальше использует его понятия.
Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта
Пляска на гробу. Автор тут утверждает что MongoDB — не реляционная БД потому что она хранит объекты виде объектов, а не таблиц.
Таблица — представление данных. Данные из Mongo можно также представить в виде таблицы. Как и данные из MySql представить в виде объектов.
А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!
Тут у читателя происходит когнитивный диссонанс.
моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели.
На данный момент у ребят уже сложились понимание, которое никак не связано с реальностью. Если вообще сложилось.
Дальше автор приводит некоторые примеры для работы с SQL. В принципе норм.
Но тут на сцену влетает foreign key!
Во первых: начинающему эта информация будет несколько сложноватой. особенно с абсолютным непониманием что такое реляционная БД.
Во вторых: foreign key по дальнейшим примерам создается, но не используется. Объяснения зачем он нужен нет.
Индексы. По тексту получается, что они сортируют данные в таблице. Часто встречал такое представление у «специалистов». Видимо тоже учились по таким материалам.
Преимущества базы данных
Каких и в сравнении с какими?
Почему используют базу, а не сохраняют данные в файликах?
БД тоже находятся в файликах
Может автор имела ввиду СУБД?
Базы поддерживают требования ACID (по крайней мере транзакционные БД)
Т.е все таки показываются преимущества именно транзакционных СУБД?
Это единый синтаксис SQL, который используется повсеместно
Еще и реляционных
Так может вывести в заголовок «Преимущества транзакционных SQL СУБД»?
Потому что эти пункты никак не относятся к преимуществам использования самих БД
=====
Автор совсем не разбирается в вопросе который она подняла. А конкретно: что такое БД. Не говоря уж о том что такое СУБД. Для чего они нужны и как их используют.
Видимо для ее квалификации на той должности на которой она находится большего и не надо.
Но чтобы не стать очередным некомпетентным «специалистом», которыми весь IT рынок завален, такие статьи обходить стороной.
=====
Какие выводы я сделал. Пока существуют такие материалы, стоимость меня как специалиста будет только расти.
Если говорить аналогиями, то мешок — это не БД, а шкаф с полками — вполне себе. Только лишь потому что в шкафу с полками, можно структурировать содержимое.
Не согласна. Полки в шкафу можно превратить в хаос, который будет явно неупорядоченным. В базу можно тоже напихунькать всякого разного не туда, и тоже получится хаос.
Это утверждение сразу зарезает понимание того что БД можно использовать и в других случаях.
Не зарезает, но может и так трактоваться, добавила фразу «в том числе»
Автор этим утверждением противоречит сама себе, как собственному определению БД, так и дальнейшим утверждением что существуют БД, использующие текстовые файлы.
Но ведь «БД, используящая файлы» ≠ «просто любые файлы».
Утверждение порождающее больше вопросов чем ответов.
У вас, потому что вы многое знаете. А у новичка это утверждение все эти вопросы не вызовет, а для понимания вполне понятно.
Очень притянуто за уши и только как частный случай.
Там тут же сказано, что это реляционная база
Объяснения зачем он нужен нет.
Есть, для связи таблиц
Так может вывести в заголовок «Преимущества транзакционных SQL СУБД»?
Вывела «реляционных»)
Какие выводы я сделал. Пока существуют такие материалы, стоимость меня как специалиста будет только расти.
Стоимость специалиста всегда будет расти. А начинающая статья никогда не сделает человека специалистом.
Полки в шкафу можно превратить в хаос, который будет явно неупорядоченным. В базу можно тоже напихунькать всякого разного не туда, и тоже получится хаос.
Я и не говорил, что нельзя. Но полки дают возможность структурировать данные. В отличии от их отсутствия.
Но ведь «БД, используящая файлы» ≠ «просто любые файлы».
Вы же опять себе же и противоречите. Нет особых файлов в которых находятся БД. Давайте посмотрим определение БД: «Хранилище структурированных данных». Всё. Тут нет ни слова о виде хранилища. Память, файлы, магнитная лента… перфокарты… Так что да, любой файл содержащий структурированные данные — БД. В том числе и «простые текстовые файлики».
А у новичка это утверждение все эти вопросы не вызовет, а для понимания вполне понятно.
Как написано, так и запомнит. Значит в будущем у новичка будут проблемы когда возникнут вопросы, или он столкнется с другой реализацией.
Есть, для связи таблиц
Это не объяснение. Что за связи? Зачем? Что будет, когда новичку дадут отлично функционирующую реляционную БД без единого foreign key? Почему вы думаете что на собеседовании не спросят что такое связи, зачем они нужны, и можно ли без них обойтись?
А начинающая статья никогда не сделает человека специалистом.
Никогда. Зато всегда может помешать в адекватном восприятии дальнейшей информации.
Так что да, любой файл содержащий структурированные данные — БД.
Не могу спорить с этим утверждением, так как файловые БД в глаза не видела. Впрочем, из начала статьи про «чем это лучше простого файлика» я убрала ещё в прошлый раз.
Как написано, так и запомнит.
Ну так пусть запомнит. Это примерно как сказать, что для простого проекта VCS не нужна. Или что для простого SVN хватит. Можно и тут докопаться и задать кучу вопросов. Можно сразу уйти в дебри пояснений, какое приложение маленькое и прочая-прочая. Но новичку это не нужно. Ему нужно понимание в целом, что можно обойтись и без этого, но с ростом объемов будет сложно. И весь пример с магазинчиком — про это. А дальше уже перекладываешь его в область ИТ.
Это не объяснение.
Ну тут уж извините. Кто-то понял, кто-то нет. Кто не понял, пойдет искать другую статью, где будет описано понятнее. В статье идет большой пример про варианты хранения и необходимость ссылки на другие таблицы. Как эта отсылка делается — вот. Чтобы понять, ЗАЧЕМ этот ключ вообще нужен — этого хватает. Если надо копать глубже — это выходит за рамки этой статьи.
Зато всегда может помешать в адекватном восприятии дальнейшей информации.
Ошибки в статьях я исправляю. Но не «мне не нравятся картинки, это какой-то детский сад», «вот тут можно объяснить подробнее, а там рассказать сильно больше». Понимание статья даёт, а уж на уровне начинающего тестировщика — за глаза. А вот неадекватно воспринимать информацию можно всегда, даже с тщательно расписанной статьей, которая каждую тему раскрывает глубоко (тем более что в такой статье легче запутаться)
Что такое База Данных (БД)