TempUserDubТаким образом, первичный ключ, согласно определению, можно использовать для идентификации каждой строки и, соответсвенно, более быстрого к ней доступа.Вам уже много раз повторили, что он нужен только для однозначной идентификации строки(записи, сущности, ...). Скорость доступа не имеет к этому никакого отношения. Не надо больше ничего своего изобретать.

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

При реализации во многих РСУБД дали возможность создавать уникальные ключи, любой атрибут которого или даже все могуть быть NULL. Несколько сомнительное решение имеющее в разных РСУБД разный смысл из-за разной же интерпретации NULL, что приводит к недоразумениям при миграции баз данных между разными платформами. Если же ни один атрибут уникального ключа не может быть NULL и это указано на уровне механизма ограничений РСУБД(NOT NULL), то никакой разницы между таким уникальным и основным ключами не существует. Если задан подобный уникальный ключ, то он же может быть объявлен основым, если такого не существует. На практике, можно не задавать ограничения типа PRIMARY KEY, если существует уникальный(е) ключ(и), позволяющие однозначно идентифицировать каждую строку, но это нередко воспринимается как дурной тон.

До тех пор пока в таблице явно не задан первичный(или уникальный, позволяющий однозначно идентифицировать строку(запись, сущность, ...) нет никакой гарантии, что в таблице не окажутся абсолютно одинаковые кортежи. IMHO, возможность создавать в РСУБД таблицы без явного указания способа идентификации строки(первичного или уникального(NOT NULL) ключей), является "медвежьей" услугой со стороны производителей и является потенциальным источником проблем.

TempUserDubПодскажите, пожалуйста, имея первичный ключ можно ли как-то быстрее\более коротким способом получить строку, чем при помощи команды Select * from Table where <имя столбца> = <необходимое значение> ?Скорость получения данных теоретически не зависит от существования первичного ключа. На практике же, она зависит только от наличия "правильных" индексов. Первичный ключ обычно реализуется с помощью уникального индекса.

TempUserDubПример - в Java в двумерном массиве можно искать необходимый элемент при помощи перебора каждой строки\ячейки. Тем не менее, если мы точно знаем какой нам нужен элемент, то мы можем сразу его получить, указав номер строки и столбца, например, Array[2][3]. В SQL вариант с командой Select, приведенной выше, более напоминает перебор массива.Как раз нет никакого перебора, SQL - декларативный язык. Вы просто указываете, по каким условиям вам нужно получить строки. РСУБД сам определяет каким способом он будет его выполнять. В частном случае, это может быть простое сканирование, т.е., перебор всех строк, пока не будут найдены все, удовлетворяющие заданным условиям. В то же время если есть "удачные" индексы, то поиск может начатся с них и только потом из таблицы будут выбираться данные, по ссылкам, полученным из индекса. Более подробно про индексы и способы доступа к данным лучше читать в учебниках или руководствах по конкретным РСУБД.

P.S. У вас какие-то свои представления о том, что из себя представляют БД. Здесь редко отвечают на подобные вопросы, обычно сразу посылают в сад почитать какой-нибудь учебник по БД, так что вам ещё сильно повезло. Хотя не удивлюсь, если вас скоро с такими вопросами таки начнут посылать.