АнатоЛой,

архитектор и разработчик БД - это разные профессии (род занятий)?

АнатоЛойТожеНачинающийАнатоЛой,

архитектор и разработчик БД - это разные профессии (род занятий)?





Архитектор ("строительный"), сварщик и каменщик - "это разные профессии (род занятий)"?! Да, их объединяет род занятий - "строительство". Но профессии даже у сварщика и каменщика разные, не говоря про архитектора.



Архитектора системы (всей), архитектора данных, разработчика БД, разработчика серверов приложений, дизайнера пользовательского интерфейса и т.д. объединяет род занятий: даже не разработка, а организация жизненного цикла автоматизированных/комп'ютеризованных/информационных систем. Но профессии у них таки разные.



Смотрите комментарий от Романа Дынника: "Есть роль и понятие архитектора данных (а не баз данных !), что не ограничивается только лишь областью БД". Да, я считаю что "архитектор данных" и "разработчик баз данных" - разные профессии.

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



Разработчик (программист/developer/programmer) БД отвечает за обеспечение работоспособности базы данных в рамках поставленного ТЗ с оговорённой СУБД, определённым набором запросов, указанными нагрузками, указанной технологией коммуникации СУБД с "внешним миром" (сервера приложений, сервера интеграции, внешние системы...).





Архитектор данных отвечает за возможность обеспечить эту работоспособность и надзор по реализации обеспечения этой работоспособности (разработчиками БД в том числе)...



Архитектор данных должен обладать знаниями/опытом, которые позволят для крупной системы:

1) сформулировать и аргументировать выбор технологии обработки и хранения данных (речь не только о СУБД);

2) аргументированно выбрать СУБД (или несколько!) при общей постановке задачи;

3) предусмотреть деление БД на крупные куски, планируя, что будет из себя представлять БД через 10 лет эксплуатации,

4) сформулировать требования к эксплуатации системы обеспечению хранения и обработки данных;

5) выбрать технологии интеграции с учётом планов развития предприятия через пару лет эксплуатации;

6) определить какую из имеющихся СУБД выбрать в качестве master-data и для каких конкретно данных.

...



Архитектор данных :

1) может сформулировать требования к данным на основании общего описания процессов;

2) может разделить большую БД на крупные куски, отдать на проектирование/разработку нескольким разработчикам, а затем проконтролировать согласованность этих кусков друг с другом.

3) может адекватно сформулировать дополнительные ограничения к общему ТЗ на систему, избавив разработчиков БД и других разработчиков от перебора множества вариантов реализации...



Архитектор данных - это тот, кто грамотно сформулирует часть Технического Задания по хранению и обработке данных в АС.

Т.е. так, что оставленная свобода выбора для разработчиков (не только БД), позволит функционировать системе независимо от выбора реализаций разработчиками в рамках указанных границ.



Любой разработчик БД может взять на себя такую ответственность? Даже если речь идёт о проекте в 5ПБ данных, 20 тыс. пользователей, большой географической распределённости центров хранения и т.п.?



П.С.: Пятилетний ребёнок при строительстве песочного замка сам себе архитектор и каменщик...

Во-первых, извиняюсь за полное цитирование...
Насколько я знаю, "архитектор" - это просто "строитель" по-русски (и на родственных нам языках и диалектах тоже).
А то, о чём вы здесь написали, - это просто модное сейчас менеджерство, "управленчество", то есть, организация любого процесса извне. При этом, по современной теории, менеджер (управленец) - может и не обладать специфическими познаниями в предметной области, но только уметь "руководить". Широко тиражируемые примеры - "ракетчик" Королёв, "айтишник"-Айфон (извините, забыл имя покойного), юрист и политолог ("недоучившийся", мягко говоря) уголовник-малолетка Янукович и т.д.
Я работал на стройке каменщиком, сварщиком, монтажником, на заводе токарем, и даже управляю юридической конторой, - и знаю, что ни один выпускник кулинарного техникума (точнее, имеющего его диплом) не сможет организовать ничего на технологически сложном, например, металлическом (или даже юридическом) производстве... "Архитекторами", видимо, работают другие рабы...

По сабжу.
Надо самому всё пробовать. Осваивать какой-нибудь программный инструмент (я лично понял всё, как устроено в этой области, из Аксесс). Читать форумы, участвовать в обсуждениях, отвечать на вопросы (пусть даже будет и неправильно - вас поправят). И - придёт Понимание.
Главное - Практика, в любых её формах. Лучший способ что-либо запомнить - попытаться пересказать другому. Практика!
(Не даром при Хрущёве нельзя было даже поступить в вуз без двухгодичной практики на производстве, любом, даже на кулинарной фабрике. И правильно: надо уже было уметь и работать, и учиться...)
Цитата предыдущего автора мне близка:
guest_20040621> Но хочется избежать изобретения велосипеда.



Велосипеды - это тоже опыт. Даже такие, которые не ездят. ;)



> Есть же общие шаблоны построения структуры БД, которые должны знать все архитекторы?



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



Проведите эксперимент: возьмите несколько обсуждений этого форума, для которых вопрос и решение не находятся на одной странице (чтобы не было возможности видеть решение как подсказку). Придумайте свой вариант решения и сравните с обсуждаемым. Удивлюсь, если будут совпадения (безотносительно вашей квалификации и квалификации задававшего вопрос).

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