Станислав Макаров

В очень широком смысле БД можно считать массив данных, о структуре которого у вас достаточно информации для выполнения необходимых вам обработок, выборок и, вообще, операций. Например, если вы смотрите на бинарник в HEX-редакторе, и даже представления не имеете, что там - видео, картинка, или же записи о сотрудниках предприятия (ну или "догадываетесь" что там, но все же не имеете в распоряжении формальных и четких правил обработки этого набора байт), то это не база данных. Если же вы знаете, что в первых 4-х байтах у вас количество записей, а дальше - сами записи о сотрудниках, длиной 150 байт каждая, и вы знаете, где в этой записи нужные вам ФИО и зарплата - то это уже простейшая БД.
Важно также, чтобы эти данные в той или иной степени отражали реальный мир: это могут быть актуальные данные, архивные (исторические) данные, но так или иначе вам должно быть известно (!), как эти данные соотносятся с реальностью. Даже если это тестовые данные, сгенерированные случайным образом - вам это должно быть известно. Иначе невозможно понять, можете ли вы в реальной системе принимать решения на основе этих данных, или нет.
Конечно в современном мире файлик с записями "базой" обычно не называют, поэтому есть и другие критерии, например, упомянутая вами связность, и возможность ее реализации. Кроме того, если говорить о системе управления БД, то у нее должен быть формальный интерфейс для выполнения запросов по обработке данных - выборок, добавления и пр.
Кстати, на вопрос проще ответить, если вы укажете конкретную модель БД - реляционную, объектную, или, например, документную. При введении модели вводятся и правила, которым должны удовлетворять данные, чтобы называться Базой данных.

EXPLAIN решает.

Для безопасности и защиты от несанкционированного удаления вы бы лучше начали использовать prepared_statements. Причем тут они? А притом, что:
1) будут выполняться только те запросы, которые вы сами написали, без риска "дополнения" этих запросов человеком со стороны;
2) логика вашего кода станет более прозрачной, и, следовательно, будет проще выяснить, нет ли нежелательных веток в нем или необработанных ситуаций. Сейчас мне пришлось сначала удивиться, когда я увидел это:
WHERE album_id={$id} {$user_name}
и потом заново все перечитать и понять, что у вас $user_name это оказывается фильтр такой. Вот когда приведете код в порядок, и будете более-менее уверены в отсутствии sql-injection, сами ответите на свой вопрос.

$what откуда берется-то? такое ощущение, что именно там оказалось "smellyshovel", непонятно зачем правда, т.к. эта ошибка явно при попытке выполнить select.

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

В C# я бы сделал ExecuteScalar:
Use the ExecuteScalar method to retrieve a single value (for example, an aggregate value) from a database. Ну т.е. как бы для этого он и сделан. О C++ говорить смысла нет без указания технологии/библиотеки доступа к данным (т.к. стандартного подхода нет и не будет).

Таблица post_category(post_id, category_id), вся запись - первичный ключ, post_id - внешний ключ на post.id, category_id - внешний ключ на category.id. Наличие записи (62, 8) в такой таблице означает, что посту 62 присвоена категория 8. Чтобы вытащить все категории поста - делаете select category_id from post_category where post_id = , все посты в категории - select post_id from post_category where category_id = .

Нет, звучит не глупо, а вполне разумно. Эта проблема (что видно из других параллельных транзакций) называется изоляцией транзакций.
Начните с чтения общих разъяснений, и конкретно о MySQL.

Попробую задать вам направление
en.wikipedia.org/wiki/Pivot_table
stackoverflow.com/questions/7674786/mysql-pivot-table

Не до конца понимаю вашу проблему. Такое ощущение, что вы все делаете наоборот. Вам же фильтры нужно сделать по характеристикам товаров? Эти характеристики уже наверное как-то хранятся у вас в базе? Если хранятся, то их и нужно использовать, зачем к товару привязывать какой-то фильтр еще? Ваши данные о товарах должны храниться так, будто у вас нет никаких фильтров.
Вот у вас таблица Items что из себя представляет? Там уже есть в каком-либо виде характеристики товаров? Может быть они еще в каких-то таблицах?

> мне нужно сделать так, что бы вставляло только в том случае, если для ключ2 не было дубликатов ключа1, а если ключ2 разные, то дубликаты ключа1 допускаются

делайте лучше одним запросом попытку найти комбинацию ключ1 и ключ2, вторым - добавление. Ну или можно положиться на constraint-ы, и просто сделать пару (ключ1, ключ2) нормальным первичным ключом - тогда мускул пошлет вас при попытке вставить второй такой же. Обратите внимание - ключом должна быть именно пара, а не два уникальных ключа по отдельности.

Я вот себе в закладки положил, и вам советую:

stackoverflow.com/questions/4048151/what-are-the-o...

Лучший известный мне список способов хранения иерархических данных в РСУБД.

Альтернативный LEFT JOIN-у вариант - оператор EXCEPT, который представляет собой операцию "минус" на множестве кортежей: en.wikipedia.org/wiki/Set_operations_%28SQL%29#EXC... . Т.е. вы выбираете все задания, и исключаете те, которые нужно... исключить:

select task.id from task
except select excluded_task.id from excluded_task
    where user_id = <id юзера>

Таблица excluded_task это пары (id, user_id) - если юзер исключил таск с некоторым id, в этом отношении будет соответствующий кортеж.

Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.

Можно попробовать абстрагироваться на уровне ORM, если таковой есть - т.е. объекты одних классов извлекаются через одно подключение к БД, другие - через другое. Если SQL-запросы пишете сами, то и думать нечего - структириуете код, как считаете естественным, и где-то в каком-то классе или контроллере (например, Logger) храните в поле необходимое подключение к БД. В другом модуле/классе - другое.