А как сейчас с работой?
считаешь что больше одной?
-----
Судя по описанию - да.
Может даже быть как у меня было - все - Оракул, но версии серверов и языков несколько отличаются.
Я вижу лишь одну тестовую БД и в строке подключения к ней явно видно, что это MS SQL Server. Но, как я говорил, в проекты подключены почему-то ещё и либы для работы с Ораклом.
Днями читал объявление о вакансии в котором, среди прочего, был перечислен с десяток баз, включая не реляционные.
Еще раз - не ДБА позици - обычный дотнет девелопер, даже вроде не сеньор...
Написать можно что угодно. Пусть попробуют найти.
С другой стороны, некоторые девелоперы же тоже в резюмах мишут всё, с чем хотя бы рядом стояли. Ну а ашар пишет всё, что было, есть и может быть. Вот такие друг друга и найдут.
Насчёт деревьев. Вот для кода я сделал тип скажем TreeNode<T>, который может принять любой объект как текущий и хранит список потомков:
TreeNode<T> Current
List<TreeNode<T>> Children
А в БД как шаблонный тип T отобразить?
В реляционной-то?
Таблица с деревом из 3х столбцов
ID, PARENT_ID, PAYLOAD_ID
Таблица объектов:
ID, DISCRIMINATOR
А как оно связано? Скажем, в первой таблице ID связан с PARENT_ID. Это просто создаёт структуру дерева.
Далее, PAYLOAD_ID связан с ID из второй таблицы? А DISCRIMINATOR описывает параметр типа Т?
Тогда не очень похоже на структуру в коде. Чтобы был аналог в коде, нужно чтобы DISCRIMINATOR мог быть ID из любой другой таблицы в БД. Ведь в коде Т может быть любым типом.
Нет, подклассы немного по=другому хранятся. Есть классы A и B. В поле DISCRIMINATOR может стоять A или B. И есть две таблицы - A и B
A:
ID, NAME, AGE
B:
ID, STREET, CITY
Насчёт деревьев.
Я думаю, что NoSQL как то больше подходят для этого
https://www.mongodb.com/docs/manual/applications/data-mode...
Хотя и для реляционных целая теория
https://stackoverflow.com/questions/4048151/what-are-the-o...
Для начала можно выбрать просто удобный для приложения способ хранения дерева, а после уже как добавить содержимое узла.
Еще то захочется какие то операции делать.
TreeNode<T> Current
List<TreeNode<T>> Children
Не, не так. Текущий - Т. А текущий узел - сам текущий объект. Правильно так
T Current
List<TreeNode<T>> Children
Из соседней темы
Там по ссылке есть "бекэнд девелопер PHP". Ну пипец обленились. У них и так ничего кроме ихнего пыхпыха знать не надо, а тут ещё и жмутся - я мол только бекэнд.
И тут:
По данным Хабр Карьеры, в мае на ресурсе разместили 4 438 вакансий:
- 1 093 — бэкенд-разработчики
- 406 — фронтенд-разработчики
- 251 — фулстек-разработчики
Я думал, чисто бек или чисто фронт канули в лету или остались лишь для самых начинающих (типа чисто фронт - лишь верстальщики). Но нет, у кого-то где-то строгое разделение и они не лезут не в свою степь. И не просто у кого-то, а это, судя по всему, мейнстрим. А в Дотнете кого ни возьми - нужно знать минимум Шарп и Джаваскрипт, плюс кучу фреймворков фронтэнда (несколько десктопных, несколько веб, что-то из мобильных). Хорошо устроились некоторые...
При этом судя по картинкам, фуллстек тебе почти ничего не даёт в деньгах. Может даже забирает. Т.е. чистый бек или фронт может даже больше зарабатывать, чем фуллстек.
Это типа российский рынок, но думаю, что примерно так же и в других странах.
Некоторые устраивают из рабочего места настоящий ад с пыточной для программиста.
"у нас было внедрённое парное программирование. В смысле постоянно за столом сидели два разработчика"
"Дежурства" - хмм, а бывает, что программист, приходя на работу, снимает свой деловой Anzug, надевает фартук или рабочую робу и объявляет - сегодня не программирую? С утра - прибраться на кухне (дежурство по кухне), затем в чатиках и логах разобраться, заявочки посмотреть, затем дежурство по кухне после обеда, потом вытереть пыль в офисе, полить цветочки, затем ещё раз пройтись по кухне, и напоследок снова пошерстить "в Кибане и Графане", пописать "техдокументацию и ОТАР (это кирпич архитектуры)" и т.п.
"команда Dev по очереди, по расписанию, занимается Ops"
...и дежурство по кухне!
Не знаю, может на других языках это не так... отстойно звучит, но на русском все эти "дежурства" отдают чем-то старым и замшелым, куда больше не хочется возвращаться. Что-то типа трудного детства. А ведь можно ещё и наказания придумывать - например, не выполнил таску вовремя - "два наряда вне очереди!".
Не могли как-то поприличнее назвать, чтобы человек может даже сам захотел "вне очереди"? Типа "выполнить почётную обязанность главного жреца по приношению очередной жертвы богу Аджайла"? Звучит?
С другой стороны, всё решается уровнем оплаты. Как говорится, "можно договориться". За быстрое вхождение в когорту семизнаков, или хотя бы "уверенных шести-", на что только не пойдёшь.
Какие там "удобные" и "восторженные" комментаторы в основном собрались. Благо, что бложик-то корпоративный, да ещё какой корпорации. Поди сослуживцы и другие менеджеры подтянулись.
Такая стратегия "все суют свой нос во все дела" неплохо работает в какой-нибудь мини-пекарне или магазине продовольственных товаров, где каждый сотрудник может и на кассе посидеть, и товары порасставлять. Потому что общий объём знаний по всему магазину или пекарне не составляет и половины знаний одного программиста. Тогда да - почему бы и не попереключать милипиздрические по объёму контексты? С большими, огромными контекстами это начинает работать ровно в противоположную сторону. Похоже, менеджерами в таких корпорациях работают сразу после менеджеринья пекарен... ну или по знакомству.
притащил какой-то высер из интернета и его смакуешь?
Это не высер. Это то, как думают менеджеры в корпорациях.
я пойду сейчас спрошу бомжа на лавке, что он думает о агильной разработке
Притащу сюда и буду комментировать ответы.
Аналогию понял?