Похоже, идея Игоря очень боится обсуждения.

Игорь очень не хочет «забалтывания» его идеи; вместо этого, он хочет просто поговорить об его идее.

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

Давайте все вместе подумаем, в каком из этих двух случаев проект утонет в «базаре».

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

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

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

Т.е. — или в проекте нужен ПОСТАНОВЩИК ЗАДАЧ ИСПОЛНИТЕЛЯМ (тогда исполнители работают по точному ТЗ, а документа «концепция» может и не быть, есть просто понимание целей проекта постановщиком задач, а исполнители застрахованы наличием ТЗ — у меня ТЗ, я его реализую, я получаю деньги, за весь проект я не отвечаю); или в проекте нужна КОНЦЕПЦИЯ, тогда ТЗ могут быть заметно более общими (неточными), исполнителям даётся больше творческой свободы, но возлагается и большая ответственность (я должен не просто реализовать ТЗ, я должен следовать канве, задаваемой концепцией проекта, и я несу ответственность за проект, а не только за свою часть, т.к. моей части НЕТ — есть большой общий проект и есть моя роль).

Наличие «концепции» не мешает существовать постановщикам задач и составлять точные ТЗ исполнителям. Т.е. постановщики могут быть и не быть, поставить точные ТЗ или не поставить.

Отсутствие «концепции» заставляет проект развиваться только одним путём — постановщики + точные ТЗ + ограниченная ответственность исполнителей.

Резюмирую: если нет концепции, нужны точные ТЗ исполнителям.
Или то, или то придётся кому-то разрабатывать.

foreign key — внешний ключ — служит для сохранения ссылочной целостности БД.
Т.е. например, у нас в каждой строке таблицы — факт начисления зарплаты кому-либо:
=== zarpl
dat date;
empl integer;
summa number;
здесь empl — ссылка на работника, т.е. id (идентификатор) работника.
соответственно есть таблица с работниками:
=== empls
id integer;
fio char(50);
если построен внешний ключ с zarpl.empl на empls.id, то удаление работника, которому есть какие-то начисления, проходит «негладко».
Если внешний ключ построен с «каскадным удалением», то при удалении работника автоматически будут удаляться и все его начисления из zarpl.
Если внешний ключ — «строгий», то при удалении работника, имеющего какие-либо начисления в zarpl, будет выдана ошибка.
Есть и другие варианты, не будем углубляться.

Грамотные проектировщики СУБД обязательно создают внешние ключи (если СУБД их поддерживает).
MySQL их поддерживает, например, для формата таблиц InnoDB.
Фактически, внешние ключи полностью отражают взаимоотношения между таблицами БД.
Именно на внешних ключах основаны алгоритмы работы средств, которые визуально отображают структуру БД. Потому что во внешних ключах — ВСЁ.

Абсолютно логично выглядит идея, что в SQL-запросе таблицы связывать необязательно. Есть ведь внешние ключи... все связки и так ясны.
Однако, это не так.

Во-первых, в ANSI SQL никаких внешних ключей нет. Там вообще слишком мало есть:)
Поэтому, все разработчики СУБД наворотили кто во что горазд, и с синтаксисом, и с возможностями.
Но в существовании ANSI SQL есть важный момент — простой SQL-запрос, написанный для скажем dBase, будет полностью работоспособным и в MySQL, и в Oracle.
Но в dBase нет внешних ключей и быть не может.
Было бы нестратегично в одних СУБД автоматом включать все внешние ключи как связки в запрос, а в других СУБД — не включать:)

Во-вторых, одна таблица может входить в SQL-запрос несколько раз. И если связки расставляются автоматически, то что с чем связывать?...
Например, пусть в таблице с зарплатой есть ещё одно поле — ссылка на бухгалтера по зарплате, который проводил начисление. Ясно, что это тоже ссылка на empls.
=== zarpl
dat date;
empl integer;
sum number;
buh integer;
Ну и пусть например есть внешние ключи — zarpl.empl->empls.id, zarpl.buh->empls.id.
и вот мы пишем запросик:
select e.fio 'сотрудник', z.summa 'сумма', b.fio 'бухгалтер'
from zarpl z, empls e, empls b
where z.empl=e.id and z.buh=b.id
И как создать такие связки, имя информацию о внешних ключах?...
С чем связать z.empl? с таблицей "e" или с таблицей "b"?