EF Core. scaffold-dbcontext. DBFirst
Есть таблица
CREATE TABLE [dbo].[Orders] (
[Id] INT IDENTITY (1, 1) NOT NULL,
[UserId] INT NOT NULL,
[IsProcessed] BIT DEFAULT (CONVERT([bit],(0))) NOT NULL,
CONSTRAINT [PK_Orders] PRIMARY KEY CLUSTERED ([Id] ASC)
);
Создаю классы вызывая при помощи Scaffold-DbContext (DBFirst):
| автор |
|---|
| PM> Scaffold-DbContext "Server=(localdb)\mssqllocaldb; Database=TestDb; Trusted_Connection=true;" Microsoft.EntityFrameworkCore.SqlServer Build started... Build succeeded. To protect potentially sensitive information in your connection string, you should move it out of source code. You can avoid scaffolding the connection string by using the Name= syntax to read it from configuration - see https://go.microsoft.com/fwlink/?linkid=2131148. For more guidance on storing connection strings, see http://go.microsoft.com/fwlink/?LinkId=723263. The column 'dbo.Orders.IsProcessed' would normally be mapped to a non-nullable bool property, but it has a default constraint. Such a column is mapped to a nullable bool property to allow a difference between setting the property to false and invoking the default constraint. See https://go.microsoft.com/fwlink/?linkid=851278 for details. |
Создается класс:
public partial class Order
{
public int Id { get; set; }
public int UserId { get; set; }
public bool? IsProcessed { get; set; }
}
Изначально поле в таблице было не нулевым, а в классе создается нулевым.
Такая особенность и как с этим бороться не понятно. Править каждый раз в ручную, при наличае более 15 классов не хочется. Есть ли какие-нибудь соображения по этому поводу?
Можно ещё сюда глянуть - там в первом ответе
Scaffold mapping on non-nullable bool · Issue #10840 · dotnet/efcore · GitHub
Было бы EF Code First, то такой проблемы бы не было. Кроме того, Code First это готовый как бы скрипт по созданию базы данных. И миграции потом тоже на нём же (Code First) писать можно. И если проект разрабатывается с приоритетом в код на Шарпе - т.е. шарповский код первичен и на нём делается главная модель приложения, то и хранилище (БД) тоже логичнее генерить из шарповских моделей - максимально близко к главной модели. Потому что реляционная модель БД и ООП не маппятся друг на друга со 100% совместимостью.
> и хранилище (БД) тоже логичнее генерить из шарповских моделей
-----
Да-да, конечно...
Специфицируй, плс, в шарповой модели... триггер.
А когда специфицируешь - добейся чтобы база его компилировала однократно...
Да, забыл... есть такая ерунда как расширения для МС СКЛ сервера - пишешь сборку, втыкаешь в сервер и юзаешь функциональность.
Недавно Я тут задавал вопросик про пару СКЛ запросов - один из вариантов решения - написать такую сборку... токма там не МС СКЛ, а Постгрее...
Ну и как ты будешь ЭТО генерить из шарповой модели?
------
Я слегка поизвращаюсь?
Насчет Коре - не уверн, не работал.
Для обычного проекта...
В проекте есть два набора команд - before & after.
Кроме этого в составе MS SQL есть утилита ISQL или что там у них сейчас...
Ну и прописываешь
DROP CONSTRAINT на before
и
ADD CONSTRAINT на after. 
Ну или два батника...
> и хранилище (БД) тоже логичнее генерить из шарповских моделей
-----
Да-да, конечно...
Специфицируй, плс, в шарповой модели... триггер.
А когда специфицируешь - добейся чтобы база его компилировала однократно...
Да, забыл... есть такая ерунда как расширения для МС СКЛ сервера - пишешь сборку, втыкаешь в сервер и юзаешь функциональность.
Недавно Я тут задавал вопросик про пару СКЛ запросов - один из вариантов решения - написать такую сборку... токма там не МС СКЛ, а Постгрее...
Ну и как ты будешь ЭТО генерить из шарповой модели?
Это просто спор о том, на чём лучше писать приложения. DBA говорят, что программисты не нужны - всё на СУБД делать можно, и нужно только прикрутить к СУБД расширения для написания GUI и прочего. Программисты говорят, что DBA не нужны, и БД можно делать на языке программирования, нужно только прикрутить расширения для создания триггеров и прочего.
Беглый поиск показал, что триггеры вкорячиваются через миграции прямо на Transact-SQL:
https://stackoverflow.com/a/56263887/5015385
Я правда не понял, что это за объект или метод Sql с кучей кода внутри - как будто в воздухе висит. Там есть метод RawSql. Но зато поддерживаются параметризованные и интерполированные строки, т.е. можно прямо из Шарпа повставлять в SQL-запрос значения и названия переменных без напечатывания их вручную в голой строке.
Но это явно решение лишь оттого, что изначально Code First не был задуман для 100% замены средств разработки СУБД. С другой стороны, сама СУБД и реляционные БД - костыль для моделей, созданных изначально на ООП.
Если бы всё (в том числе средства хранения данных) изначально для ООП точилось, то не нужны были бы маппинги и прочий костылизм.
Я могу вызвать код Transact-SQL через C# (ну или отправить в СУБД на исполнение), а можно ли в БД через Transact-SQL вызвать код C#?
Ещё можно смешивать коды SQL и C#, а вот наоборот - навряд ли. Вот пример с интерполированной строкой в LINQ
var blogs = context.Blogs
.FromSqlInterpolated($"SELECT * FROM dbo.SearchBlogs({searchTerm})")
.Where(b => b.Rating > 3)
.OrderByDescending(b => b.Rating)
.ToList();Вообще, БД должна только хранить данные. Триггеры и хранимые процедуры - вообще любая логика - это уже "программирование на СУБД", и вынос логики в СУБД. Этого не должно быть. Вся логика в БД должна только обслуживать саму БД и никаких операций с данными не делать. А то борятся-борятся за разделение ответственности по слоям, а потом пихают всё куда попало. Или дублируют логику - типа своя валидация в каждом слое.
И даже в этом идеальном мире это не про то, что пациент пишет.
На триггер возбудился, сразу "логику" увидел. Как дальше жить...
Когда у меня 1 запись на миллион чтений я могу кучу триггеров понаделать. Лишь бы чтение/поиск ускорить. И к "логике приложения" это не будет иметь ни малейшего отношения.
Когда у меня 1 запись на миллион чтений я могу кучу триггеров понаделать. Лишь бы чтение/поиск ускорить. И к "логике приложения" это не будет иметь ни малейшего отношения.
Если ваши триггеры-процедуры обслуживают работу БД, оптимизируют запросы, а не выполняют бизнес-логику проекта, то норм. Но некоторые специалисты по БД пытаются в БД засунуть и бизнес-логику, а потом говорят разработчику приложения "подёргай хранимки", вместо того, чтобы реализовать это в слое бизнес-логики.
так можно дойти и до того, что будем ключи в таблицах запрещать
Ключи нужны для создания реляционных связей. Но по идее, у вас уже есть связи в бизнес-логике. Вы зачем-то дублируете эти связи в БД, но по правилам БД, где не всё можно отобразить на бизнес-слой (и наоборот). А потом через слой работы с БД (ORM или ещё какой паттерн хранилища данных) сглаживаете углы и несовместимости. И вот у вас уже три слоя, с тремя моделями, которые все означают примерно одно и то же, при этом один слой существует вообще лишь для интеграции двух остальных.
Если бы можно было затолкать всю БД в оперативку, то и БД с ORM не понадобилось бы. Тем более, насколько мне известно, СУБД и так в своих оптимизациях держит наиболее часто выполняемые запросы или подзапросы в RAM (или что-то подобное - типа кеша).
То, что создатели баз данных пытаются на своих расширениях SQL целые приложения писать, это как некоторые фронтэндщики пытаются протолкнуть в CSS вычисления и далее продвинуть это, судя по всему, до ещё одного языка программирования. Расширения SQL были сделаны для того, чтобы немного облегчить работу DBA, а не позволить им писать полноценные приложения. Javascript и CSS были придуманы, чтобы немного облегчить жизнь создателям интернет-страничек, а не позволить им писать полноценные приложения. Но всё пошло не по плану...
изначально Code First не был
-----
Он и сейчас до этого не дорос.
По секрету скажу - и не дорастет никогда. Просто это не его область.
Область применения этого инструмента - очень узкая. Очень мелкие базы... по паре-другой тысяч строк на таблицу... прототипирование... ну еще пара мелочей. Для всего остального надо брать ДБА... и менять код под его продукцию.
а можно ли в БД через Transact-SQL вызвать код C#?
-----
Как минимум двумя способами.
Первый - сборкой добавленной к инстансу сервера.
Второй - ловлей эвентов сервера... это как раз к вопросу об тригерах.
изначально Code First не был
-----
Он и сейчас до этого не дорос.
По секрету скажу - и не дорастет никогда. Просто это не его область.
Область применения этого инструмента - очень узкая. Очень мелкие базы... по паре-другой тысяч строк на таблицу... прототипирование... ну еще пара мелочей. Для всего остального надо брать ДБА... и менять код под его продукцию.
Я не знаю СУБД так глубоко. Для повышения производительности таблицы в частности и БД вообще обкуриваются какой-то особо забористой оптимизационной травой, которую не вдохнуть через Code First?
Или прямо каждый второй - Гугл и у них миллионы записей в таблицах и сотни тысяч транзакций каждый день?
Ага. Гугол. Сотни тысяч каждый день... А сотни тысяч каждый час месье не желает? Для магазина "машины носочки" Code First отличное решение. Для страховки/банка/сети магазинов - убийственная тупость. Даже с поверхностными знаниями SQL и конкретной RDBMS можно превзойти результаты code first на порядки.
Из личного опыта: ускорение чтения более чем в 600 раз. Вместо 10-15 минут до 0.5 - 1.5 секунд. Просто убрали сложный ключ (заменили интом) и сэкономили пару десятков джойнов (добавили триггер, копирующий PK созданной записи в одну табличку).
А проблема, из-за которой я Code First ненавижу, аж кушать не могу, в том, что частенько проект начинается как "машины носочки" а через два года "класс! а теперь выкатываем это в продакшен для 10.000 филиалов! Что значит работать не будет? Что значит проще переписать заново чем доработать?" Я уже не знаю с каким количеством проектов я так мучался.
не обязательно быть Гуглом, чтобы насобирать за год 100500 миллионов строк мусора.
там уже не до розовых соплей, там берётся за дело 59-летний коллега и изучает Execution plan.
Ну т.е. не меня и какого-нибудь другого джуниора-миддла запрягают? А то на некоторых собесах так спрашивают, будто джуны им в одно рыло Гугл поднимают. Т.е. берём и делаем базу на EF Code First, а когда припрёт, зовём пенсионера, чтобы процедурок-триггеров нам в базу накидал? Reicht?
Ага. Гугол. Сотни тысяч каждый день... А сотни тысяч каждый час месье не желает? Для магазина "машины носочки" Code First отличное решение. Для страховки/банка/сети магазинов - убийственная тупость. Даже с поверхностными знаниями SQL и конкретной RDBMS можно превзойти результаты code first на порядки.
Ребята-ребята! Code First - это для программиста по-быстрому БД накидать, и заодно чтобы скрипт создания БД не писать на SQL. Ваш DBA не знает C# скорее всего, так что ему ни Code First, ни Database First не сдался - это вообще не для него. Если вы делаете второй Гугол или Дойчебанк там, то явно не вешаете все задачи на одного программиста, а имеете целую команду DBA и прочих специалистов, так что программист не лезет в создание и управление базами данных, а DBA - в код приложений, так? Тогда спора нет - нафиг этот Code First не сдался.
What is Code-First?Entity Framework introduced the Code-First approach with Entity Framework 4.1. Code-First is mainly useful in Domain Driven Design.
What is Code-First? (entityframeworktutorial.net)
Кстати, ASP.NET MVC уже устарел (все версии) - теперь рулит Razor Pages (синяя плашка по ссылке Tutorial: Get Started with Entity Framework 6 Code First using MVC 5 | Microsoft Docs).
а через два года "класс! а теперь выкатываем это в продакшен для 10.000 филиалов! Что значит работать не будет? Что значит проще переписать заново чем доработать?" Я уже не знаю с каким количеством проектов я так мучался.
Нормальный подход. Или вам нравится вечно со старым дерьмом работать? Нужно же думать заранее, чем вы через два года заниматься будете. ))
Один раз ради интереса попробовал и больше не смог.
Ну удобнее c ER дизайнером работать. Все база видна, нет зависимости от используемой версии EF, и генериш что надо.
Только в подходе "сначала код" ты должен разбираться лишь в сишарпе (ну и немного в конвенциях EF), а в подходе "сначала база" вы должны быть виртуозом графического дизайнера БД. Так недалеко и до Visual programming language - Wikipedia опуститься. Просто вам непривычно, потому что вы с графического дизайнера начинали.
Или прямо каждый второй
-----
Данные имеют свойство накапливаться.
Причем - довольно быстро.
Той базе, которую Я делал для системы импорта, проблемы производительности появились уже на второй год эксплуатации.
Решение проблемы известно - нужно добавлять индекс по паре полей...
сотни тысяч транзакций каждый день?
-----
Импорт 20-30 документов в день...
Документы в базе не хранятся - хранится только (подготавливаемые однажды) "значения по умолчанию" для каждого клиента и типа обработки. Клиентов - десятка два, обработок - потенциально 9999, используется много меньше.
Итого - 20.000 записей начинают генерировать проблемы производительности.
Нормальный подход. Или вам нравится вечно со старым дерьмом работать? Нужно же думать заранее, чем вы через два года заниматься будете. ))
А попробуйте угадать - сколько раз разрешили переписать заново? Из .... ну пусть для удобства будет 10 проектов.
Все база видна
-----
А это - плохо.
Как прикладник ты базу должен видеть только в том виде в каком ее тебе даст ДБА.
С дугой стороны - когда контора мучает хомяка по паре недель на страничку обучение персонала написанию 80-90% тестируемого кода путем глядения только в схему базы дает существенный прирост общей производительности...
чтобы процедурок-триггеров нам в базу накидал?
-----
А оно решит проблему?
Выше же уже написано - Что значит проще переписать?
Был такой маленький кусочек - планировщик смен.
Ничего страшного - пара-другая табличек - когда, от скольки до скольки работаем, выкинуть выходные, отработать выходной как исключение и т.п...
Такой маленький самопальный планировщик с кучей неправильных записей, с совершенно неправильными расчетами и кучей глупостей типа вот мы всю маленькую таблицу поднимем и потом выберем что нам надо, а тут поменяем и потом вернем...
Так Я его не смог заменить - им пользовалось 2 Гб спагетти-кода... где-то, как-то что-то вынималлось, как-то обсчитывалось, каждый раз это делалось по-другому т.к. в конкретном месте нужен был "не такой" результат и получить его можно было только обработав имеющиеся ошибки определенным способом...
Чтобы его заменить - надо переработать все 2 Гб спагетти...
потому что вы с
-----
Для умных: мне без разницы что использовать код- или - база- первым.
Но так как Я знаю об базах немного больше чем знает знает пользователь код-первым, то мне видно что именно эта технология не позволяет мне сделать с базой. Того что она не позволяет делать из того что Я знаю и могу использовать следует однозначный вывод - база-первая.
Если не все еще не понятно - напиши представление... хммм... обычного адреса... т.е. как обычно - фамилия имя отчество, страна, город, улица, дом, квартира, почтовый индекс... пыхх... чего там еще... аааа... у нас в Ирландии не всегда есть город и улица, но есть графство - используются имена собственные для домов... ну еще нюансы в других странах... и уложи это в базу. Потом просто уложи туда... у нас более 100 стран... хммм... ну скажем по 30 млн записей на каждую страну. И заставь это все работать быстро... Разумеется используя Коде-Фирст... Когда поймешь в чем проблема - посмеемся вместе...
разбираться лишь в сишарпе
Не считая соглашений о генерации таблиц из кода
виртуозом графического дизайнера БД
Да любой школьник нарисует там таблички с колонками.
с графического дизайнера начинали
точнее с листа бумажки
Не нашел просто ни одного преимущества, особенно в долгосрочной перспективе.
Хотел вот недавно старый проект обновить, а фиг вам - нет совместимости пишет.
Да и смотреть на энто или на код две разные вещи.
И ДБА вживую никогда не видел
-----
Так и слава богу - не допустил господь до греха...
Тем не менее - видеть базу, как прикладник, ты должен только в том виде в каком ее даст ДБА.
А как она реально выглядит - тебе занать не надо... и даже вредно.
Просто посмотри на описанное выше и подумай - ну зачем тебе детали организации хранения адреса, если адрес ты видишь как указано?
Или прямо каждый второй
-----
Данные имеют свойство накапливаться.
Причем - довольно быстро.
Той базе, которую Я делал для системы импорта, проблемы производительности появились уже на второй год эксплуатации.
Решение проблемы известно - нужно добавлять индекс по паре полей...
Чистить периодически?
Нормальный подход. Или вам нравится вечно со старым дерьмом работать? Нужно же думать заранее, чем вы через два года заниматься будете. ))А попробуйте угадать - сколько раз разрешили переписать заново? Из .... ну пусть для удобства будет 10 проектов.
Переписывать софт, хотя бы кусками - это нормально и должно быть заложено в долгоподдерживаемом софте. Рефакторинг же к этому относится? Если менеджеры не дают этого делать, значит они плохие менеджеры, думающие только о своих показателях и премиях, и не хотящие понимать элементарных вещей.
С какого-то времени поддержка старого софта без переписывания становится дороже переписывания. Ну, так во всех областях, не только в софте. Софт тоже протухает, ржавеет и распадается на атомы.
Ну удобнее c ER дизайнером работать. Все база видна, нет зависимости от используемой версии EF, и генериш что надо.
Насчёт "вся база видна" - тоже спорно. А если у меня монитор маленький или таблиц за сотню? Что толку созерцать сотню квадратиков с несколькими сотнями связей между ними на одном мониторе - ничего не понятно же.
Вот три примера подобного визуального подхода
Все эти визуальные схемы - только для самых простых проектов, фактически учебных примеров.
А попробуйте угадать - сколько раз разрешили переписать заново? Из .... ну пусть для удобства будет 10 проектов.
Всякие крупные магазины и вообще большие компании, начиная от Гуглов, заканчивая средними банками, ретейлерами и прочими, переписывают свои сервисы каждые несколько лет. Дайте догадаюсь, почему? Приходит новый тимлид или мода меняется, и теперь всё не на Реакте, а на каком-нибудь Ангуляре - и вся минимум морда магазина или сервиса переделывается.
А бывает, что менеджерам просто надо показать свою нужность и занятость, поэтому переписывают просто чтобы переписать. Скругляют углы интерфейса, потом снова спрямляют - и так до бесконечности.
Чтобы было понятнее - систему сделали, бюджет исчерпан.
Кому и какими деньгами ты собираешься платить за модификацию стандалонного АРМа под "10.000 филиалов"?
Систему сделали, бюджет исчерпан. Приходит заказчик через 2 года и говорит доделать-переделать. А у вас те люди, что делали эту систему, уволились, а версии фреймворков изменились, а часть поставщиков библиотек вообще отвалилась и больше библиотеки не поддерживает. Короче, проще всё переписать... Ну, всякие НАСА ещё пытаются искать фортранщиков для некоторых своих древностей, но обычно это исключение, а не правило.
Так Я его не смог заменить - им пользовалось 2 Гб спагетти-кода... где-то, как-то что-то вынималлось, как-то обсчитывалось, каждый раз это делалось по-другому т.к. в конкретном месте нужен был "не такой" результат и получить его можно было только обработав имеющиеся ошибки определенным способом...
Чтобы его заменить - надо переработать все 2 Гб спагетти...
И вы сказали об этом начальникам, или побоялись увольнения? Как я понимаю, в таких случаях должны решать начальники (если ты сам не начальник) - переписывать с нуля, или продолжать поддерживать неподдерживаемое.
Проблема только в том, что мне попадались только две вещи или база есть или ее нет. И ДБА вживую никогда не видел
Все работают в маленьких конторах в малюсеньких командах (зачастую состоящих из одного человека), где даже уборщица - фуллстек (заодно секретарша, любовница шефа и подрабатывает техподдержкой).
в том виде в каком ее даст ДБА.
ну и в каком виде обычно тебе ее давали?
тебе знать не надо... и даже вредно
не знаю, как у тебя, но у меня обычно нижняя точка для работы с базой - это работа с конкретными таблицами.
Даже запрос какой-то необычный сфарганить и то нужно знать как там таблицы связаны и что там накручено.
Всякие крупные магазины и вообще большие компании, начиная от Гуглов, заканчивая средними банками, ретейлерами и прочими, переписывают свои сервисы каждые несколько лет.
Бугагашеньки. Ага. Переписывают. Каждые несколько... десятилетий. Когда куча скотча и соплей уже не могут поддерживать слепленное дендрофекальное угробище.
Ну и на вопрос вы не ответили. Так что открываю карты - ни разу, №;%:. Экванамисты и особенно топы это редкостные мрази. Им насрать на всё кроме их бонусов. Сэкономил миллион на ИТ - маладца, получи бонус! А то что проект разваливается и через 5 лет надо вбухивать 20 миллионов, менеджера ниипёт. Он уже давно ускакал на другой проект или в другую фирму - бонусы собирать.
Единственное что помогает - при малейшем шансе что из этого проекта может вырасти что-то большое, делать его максимально стабильным. Никаких "модных технологий, ускоряющих разработку", в которых все делается "по волшебству фреймворка". Всё что делается должно быть понятно минимум 5 программистам. Всё документируется. Ну или сваливать с фирмы вместе с менеджером. Переделывать 15-и летнее угробище - очень страшная задача.
Чистить периодически?
------
Если "почистить" - девочкам придется "дефаулты" готовить по-новой.
А там - надо знать тех.процесс и понимать что делаешь... если чего не так - потом в ручную править - это медленно и не все могут...
это нормально
-----
Блин, ну когда ты начнешь экономику учитывать...
Элементарно же - за новую функциональность что-то платят, за исправление чего-то там, что не сказывается на функциональности/производительности - как правило - нет...
Вообщем - берешь отпуск за свой счет и пару лет доводишь кусок кода до идеала.
Потом считаешь что в кармане и говоришь себе - "это нормально".
запрос какой-то необычный сфарганить и то нужно знать как там таблицы связаны и что там накручено
------
Это потому что ты в область ДБА влазишь.
Если не влазишь - для тебя база "плоская"...
ну и в каком виде обычно тебе ее давали?
------
В таком, что приходилось объяснять ДБА где у него ошибка... 
Иногда - исправляли, иногда не исправляли и потом вылазило...
Но сути это не меняет - есть работа ДБА и пусть он ее делает... как умеет.
Переделывать 15-и летнее угробище - очень страшная задача.
-----
Он этого пока не понимает...
Ну да ничего - поработает пятилетки три-четыре, поменяет десяток-другой шаражек - начнет думать что и как...
Каждую следующую ведь будет найти сложнее, чем вторую-третью... хотя и проще чем первую.
в том виде в каком ее даст ДБА.ну и в каком виде обычно тебе ее давали?
Я обычно сам всё делал. В том-то и штука, что я в командах нормальных и больших никогда не работал. Либо всё сам делаю, либо лишь некоторую часть делает другой человек (типа работы с железом и Лабвью), а остальное всё равно я сам.
Если я увижу БД, и надо будет с ней работать, я просто натравлю на неё Entity Framework и буду работать через ORM.
Даже запрос какой-то необычный сфарганить и то нужно знать как там таблицы связаны и что там накручено.
А как вам такое задание
NET und C# ohne Web? - Щас глянул один видос ютубе Типичная - Программирование (germany.ru)
Всякие крупные магазины и вообще большие компании, начиная от Гуглов, заканчивая средними банками, ретейлерами и прочими, переписывают свои сервисы каждые несколько лет.Бугагашеньки. Ага. Переписывают. Каждые несколько... десятилетий.
В том-то и дело, что переписывают. Пользовался долго банком, магазином, ещё одним банком, сервисом по продаже билетов и ещё до кучи. Ни один не продержался с одной и той же мордой хотя бы 5 лет - всё было заменено на модные технологии. Был раньше десктопный и мобильный вариант? Теперь один адаптирующийся. Был раньше адаптирующийся, но на старом фреймворке? Теперь на новом, с новым "плоским" дизайном.
Про всякие гуглы-ютубы и не говорю. Там если три года что-то не менялось радикально, то, похоже, дизайнеров просто увольняют. Поэтому они изо всех сил стараются хотя бы иногда скруглять-распрямлять углы интерфейсов и менять цветовые схемы. Ну заодно и движки под этим всем обновляют. То, что оно раньше работало быстрее, а теперь тормозит и жрёт больше памяти - никого не волнует.
И вы сказали об этом начальникам, или побоялись увольнения?
------
Сказать - сказал. И даже 6 лет что-то делал для решения проблемы.
Но 2 Гб спагетти-кода есть 2 Гб спагетти-кода...
И что вам не нравится? Хорошо устроились (анекдот про сына адвоката). )))
запрос какой-то необычный сфарганить и то нужно знать как там таблицы связаны и что там накручено
------
Это потому что ты в область ДБА влазишь.
Если не влазишь - для тебя база "плоская"...
Судя по видосам типа такого, на просторах СНГ и Восточной Европы как минимум (да и везде, похоже), все лазиют во все области во всех направлениях. Этакое броуновское движение фуллстек джуниоров по проекту.
Ну да ничего - поработает пятилетки три-четыре, поменяет десяток-другой шаражек - начнет думать что и как...
Каждую следующую ведь будет найти сложнее, чем вторую-третью... хотя и проще чем первую.
Из-за возраста?
И что вам не нравится?
-----
6 лет отставания в технологиях мне сильно не нравится.
Мне так же сильно не нравится спускание в унитаз 70% наработок... Я бы понял если бы взамен было предложено решение, но там лишь увечат количество спагетти... и в конце концов зашьются с модификацей оного...
В таком, что приходилось объяснять ДБА где у него ошибка...
Я просто поражен качеством ответа на казалось бы простой вопрос. Ну да ладно - просто интересно было. 
Это потому что ты в область ДБА влазишь.
И как интересно не влазить? Дали тебе доступ к базе с каким но непонятным описанием, что дальше?
Из-за возраста?
-----
В том числе и возраста.
Но когда тебя несколько раз подряд выкинут из шараги с формулировкой - не тянет - следующий сильно подумает надо ли тебя брать...
К "не тянуть" относятся такие вещи, как отказ от сверхурочных, отказ от выполнения работы не по профилю (Алекс, мы знаем, что ты шарпист, но на следующей неделю ты будешь джавист и немного джаваскриптер), отказ от незапланированных командировок и т.п. отказы?
Судя по видосам типа такогоКраткое руководство по разработке спагетти приложения
Там в видосе парень рассказывает, что так сильно боялся, что его выгонят (а его уже раз выгоняли поначалу - как раз с формулировкой "не тянешь"), что ни от чего не отказывался и брался за любую задачу, что ему давали, на любом языке, несмотря на то, хватает ему компетенций или не хватает. По крайней мере, я так его понял.
ты себя как-то сильно на негатив настраиваешь
Айти это сейчас священная корова
Напомнило
"не тянуть"
-----
Означает, что проект не уложился в запланированные сроки и самым малым вкладом в общий результат оказался твой...
Еще раз скажу - у тебя ооочень "совковый" подход к работе - тебя приняли забивать гвозди - ты их и забиваешь... при этом закрутить шуруп - это уже за пределами возможного... даже если следствием остсутствя закрученного шурупа будет потеря возможности забивать гвозди.
К "не тянуть" относятся такие вещи, как отказ....
Слишком примитивно
Есть проект - "телега". Ее нужно вытянуть на гору, каждый член команды ее как то тянет. Шеф не стоит с плеткой, но очень хорошо замечает, кто, как и куда ее тянет.
Можно работать по 10 часов, писать на яве, ездить куда угодно и все равно "не тянуть".
Но это нужно хотя бы пару лет здесь отработать, чтобы врубится в принцип.
В любом коллективе всегда найдутся самые неэффективные, независимо от того, насколько хорошо они работают. Принцип "постоянно увольняем низшие 10%" - кажется, от него такие фирмы, как Майкрософт, недавно отказались. Зачем нанимать джуниоров, если они всегда будут не тянуть по сравнению даже с миддлами? Чтобы через половину испытательного срока их уволить? Кажется, Амазон занимается "наймом под увольнение"?
если они всегда будут не тянуть
Ну отчего же? Разный есть народ.
Но опять таки, все подобные дискуссии совершенно бессмысленны, пока вы сами всё не почувствуете.
У каждого свой угол зрения и собственный опыт. У другого может все абсолютно противоположно.