Как научиться строить модели БД sql в связке с С# (Цель- писать понятные ТЗ для программистов С#)?

Question

[Дмитрий Ларгович]

Приветствую.

Занимаюсь аналитикой, т.е. пишу ТЗ. Планирую перейти в системные аналитики. Знаний, в т.ч. практических, по базам данных, по sql у меня нет.

Сообщили, что в той конторе в которую перехожу, программисты С# (разработка ведется на этом языке) мало знают sql. И что их системному аналитику нужно будет в ТЗ также прорабатывать, описывать вопросы взаимодействия с базой данных sql. Чтобы по этому ТЗ программисты четко понимали что и куда и как.

Подскажите пжта какие либо обучающие онлайн курсы (желательно на русском), книги, практические онлайн-задачники и др. ресурсы для быстрого обучения? Было бы важным узнать мнение и С# программиста.

Answer 1

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

Сложно вам посоветовать в такой ситуации что-либо. Интересно, чем занималась контора та, что программисты C# с sql не знакомы, разве что играми..
В целом вам надо ознакомиться с современным представлением о реляционных БД (вы же все-таки аналитик, вам нужно знать на разных уровнях и масштабах), с архитектурой приложений, использующих РБД (толстые и тонкие клиенты, веб-приложения), и потом уже некоторые детали касающиеся языка.
С точки зрения программиста C#, я бы от вас как от аналитика ожидал знание различных принципов и дисциплин доступа к рел. данным, а именно:
- использование ORM: когда можно и нужно), когда хочется, но нельзя, когда можно "толстую" ORM (Entity Framework, NHibernate), а когда - тонкую (LINQ to SQL); использование кода на стороне БД - триггеры, хранимые процедуры;
- принципы построения слоев доступа к данным в сочетании с бизнес логикой (паттерны и антипаттерны в этих ситуациях, например Anemic Data Model);
- способы контроля версий схемы реляционной БД - миграции, source control для триггеров и хранимых процедур (если они есть), политики обновления схемы вместе с выкатыванием новой версии ПО;
- формирование тестовых данных в тестовых базах;

Вот если сможете по этим вопросам проконсультировать, то разработчикам останется только подучить SQL и конкретную ORM, если будете использовать.

Comments

[asArtem]

- использование ORM: когда можно и нужно), когда хочется, но нельзя. - для бизнеса можно всегда, кроме случая когда у вас ботлнетрм является скорость обработки запроса ORMомо, что на практике мало достижимо и есть много чего другого оптимизировать чем трансляцию Expression в SQL. Обычно отказ от ORM это из-за неграмотности команды, где в качестве архитекторов системы сидят бывшие DBA и любители всё засунуть в хранимки, либо особенности архитектуры(например делая оболочку для MSSQL Studio нет смысла использовать ORM потому что надо напрямую писать в БД)

когда можно "толстую" ORM (Entity Framework, NHibernate), а когда - тонкую (LINQ to SQL); - вопрос столь несущественен, что надо брать ту, которую команда уже знает. Как правило это EF или Nh ну и к тому же рано или поздно захочется большего, а LtS не способен на большее. В итоге знать не надо, надо брать. И выбор делает программист, а не аналитики.

использование кода на стороне БД - триггеры, хранимые процедуры;
- принципы построения слоев доступа к данным в сочетании с бизнес логикой (паттерны и антипаттерны в этих ситуациях, например Anemic Data Model);

Вот это надо знать. Особенно про анти-паттерн Active Record.

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

@asArtem
> для бизнеса можно всегда
да там просто непонятно какой бизнес, что народ sql не сильно знает. В highload например orm-ки не любят, т.к. вылизывают каждый запрос руками. А так, для обычного enterprise конечно подойдет orm в 99% случаев.
> когда можно "толстую" ORM
> которую команда уже знает
да вот непонятно, что они вообще знают)). Видимо автор вопроса как раз и должен подсказать им.

Конечно да, если это все будет выбирать аналитик, то это уже не только аналитик, но и тимлид. Видимо кем-то вроде тимлида ему и предстоит быть)

[asArtem]

Станислав Макаров: есть мнение, что команда-таки всё знает, просто манагер тупой.

[Дмитрий Ларгович]

Станислав Макаров: Да, аналитик должен подсказывать им) Спасибо!

[Дмитрий Ларгович]

Станислав Макаров спасибо большое за ваш труд и дельный совет!

Answer 2

[asArtem]

программист C# не знающий SQL это что-то странное. Это гос. контора, где работают эникейщики за 10 тыр?
Я на 99.9% уверен любой из их кодеров SQL будет знать лучше вас даже после курсов и года опыта работы аналитиком с SQL.
>> в ТЗ также прорабатывать, описывать вопросы взаимодействия с базой данных sql
тут 2 вариант:
первый реально работать несколько месяцев с базами данных как DBA или программист. Иначе все ваши потуги с построением архитектуры БД это сущий бред будет. Руки оторвать манагерам, которые это собираются допустить.
второй вариант: брать DBA или опытного программиста, он будет строить архитектуру базы данных, вам быстро объяснять ,а вы со знаниями и пониманием баз, связей, таблиц будет некоторые подробности выдавать программистам. Это самый логичный вариант.

А в целом системный аналитик, который составляет столь подробные ТЗ, что пишет в какую таблицу класть и почему именно так - это адовый треш. Нет, когда у разработчика вопрос "где мне посмотреть список заказов и какие там связи", то DBA или старший программист или их техлид или архитектор - кто-то из них должны овтетить, т.к. они и отвечают за реализацию. Но аналитик?!
Аналитик может только указывать бизнес-связи сущностей предметной области. До уровня BPMN диаграмм ну или диаграммы потоков данных. Всё. лезть в базы данных строго запрещено (кроме случаев, когда аналитик - бывший разработчик и реально шарит).
Ваш потенциальный работодатель неадекватен, если он планирует все делать именно так, как сказали вы.

Но если настаиваете, то вперёд учить SQL c нуля (в поиске забить), а также всё что можно по базам данных. Конкретных учебников для рекомендации нет, вам любой подойдёт. Включая интерактивные курсы по базам данных на intuit.ru и на pluralsight.com (их видосы можно скачать на рутрекере)

PS я сам разработчик и как раз на C#

Comments

[Дмитрий Ларгович]

Артем спасибо большое за столь подробный ответ. Мне это очень нужно было, ну и конечно подписчикам на этот вопрос.

Answer 3

[Дмитрий Ковальский]

А еще есть шанс отказаться? Суда по вашей исповеди - в команду, плохо знающую sql в качестве консультанта отправляют человека который его не знает вовсе. Звучит пугающе. https://www.codeschool.com/courses/try-sql тут попробуйте начать. Ну и поискать на тостере. Вы не первый задаетесь этим вопросом https://toster.ru/search?q=изучение+SQL

Comments

[Дмитрий Ларгович]

Да есть) Спасибо за рекомендацию! Мне нужно понимание что нужно, какие знания БД и построения моделей БД, чтобы результами моей работы в виде ТЗ ясно понимали программисты С#. Такого вопроса не было, поэтому и создал) Обязательно посмотрю курсы)