ReSQL.ru
     
powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Наши за рубежом [закрыт для гостей] / Что происходит на рынке DB вакансий в ЕС?
25 сообщений из 375, страница 11 из 15
  11  все
Что происходит на рынке DB вакансий в ЕС?
    #21633015
kDnZP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kDnZP
Участник
stenford, кодогенерация ORM не идеальна и если на чем-то простеньком она существенно упрощает и удешевляет разработку, то на более-менее объемных или нагруженных решениях приходится идти на компромиссы и мало полагаться на ORM. И это не только про Linq, а в целом, т.к. я еще ни разу не видел кодогенерации, которая меня лично бы устроила. :) Впрочем то, что кодогенерация плоха, вовсе не значит, то программист напишет код лучше - проверено. Оптимальная стратегия ИМХО - реализация функционала, а затем рефакторинг и оптимизация, с периодической регрессией.

* Чтобы понимать о проектах о который говорю, к примеру на прошлой работе это был MS Dynamics AX, но речь не только о ERP, а в целом.
...
Рейтинг: 0 / 0
07.08.2018, 15:15
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633023
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
CawaSPb 
Кстати, будет ли именно в Вами используемом ORM такая конструкция оттранслирована в предикат на уровне SQL, или будет производиться пост-фильтрация на уровне приложения?
конечно на уровне SQL, в этом весь смысл
...
Рейтинг: 0 / 0
07.08.2018, 15:18
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633032
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
kDnZP 
stenford, кодогенерация ORM не идеальна и если на чем-то простеньком она существенно упрощает и удешевляет разработку, то на более-менее объемных или нагруженных решениях приходится идти на компромиссы и мало полагаться на ORM. И это не только про Linq, а в целом, т.к. я еще ни разу не видел кодогенерации, которая меня лично бы устроила. :) Впрочем то, что кодогенерация плоха, вовсе не значит, то программист напишет код лучше - проверено. Оптимальная стратегия ИМХО - реализация функционала, а затем рефакторинг и оптимизация, с периодической регрессией.

* Чтобы понимать о проектах о который говорю, к примеру на прошлой работе это был MS Dynamics AX, но речь не только о ERP, а в целом.
там, где используются ORM удешевление (и улучшение качества) есть всегда. Есть системы где ORM по определению не нужны, и конечно там от них только вред. И зависит это не от размера системы или ее сложности, а от типа.
...
Рейтинг: 0 / 0
07.08.2018, 15:22
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633104
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
stenford 
Megabyte 
Можно пример функционала, когда на сервере тысяча хранимок(для чего?), а на клиенте 1 метод? Мне просто сложно это представить... Обычно 1 метод на клиенте равен 1 хп на сервере.
Кто вам мешает все вызовы в БД завернуть в один метод верхнего уровня, как вы сделали с клиентским кодом?
есть к примеру таблица с клиентами Client (Name, Surname, DOB и еще 20 полей). Одной подсистеме надо клиентов отбирать по имени + фамилии, другой - по дате рождения, третьей - по адресу. С хранимками у вас 2 варианта - иметь 3 хранимки (с такими замечательными именами как GetClientsByNameAndSurname), либо иметь одну хранимку с десятком параметров и лестницей из case'ов внутри (либо ручным динамическим sql).
С ОRM будет один метод DAL IQuerable GetClients(). Вызывающие подсистемы просто вызовут его как GetClients().Where(c => c.Name == 'Alex' && Surname == 'Ivanov'). Все остальное сделает ОRM.
Теперь для следующей версии понадобится фильтр по наличию у клиента детей. Вы будете либо создавать новый DAL метод + новую хранимку, либо добавлять новый параметер с новым case'ом в существующую (и заодно перетестировать весь код что-бы убедится что ничего не сломалось). А мне в буквальном смысле слова не надо будет ничего делать. Подсистема просто вызовет мой метод как GetClients().Where(c => c.Kids > 0)
Когда клиентов в таблице 100-1000, то да, код ОРМ будет немного проще. Я согласен, что можно и ОРМ заюзать.

А если разобрать другую ситуацию: таблица, например, 100млн транзакций. Будешь ли ты обращаться к ней по какому угодно фильтру то, на выбор:
1) будешь жрать ресурсы на скан таблицы и мешать другим пользователям, если не положишь систему в целом.
2) натыкаешь индексов на все возможные поля и поимеешь производительность на вставку\апдейт\удаление записи.

И вот какой-то программист, который вдруг захочет по этой таблице отфильтровать по какому-то второстепенному полю, запустит внезапно скан всей таблицы, будет веселуха.

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

Так-то у нас у разрабов у всех доступ, поэтому приходится их код постфактум оптимизировать. :) И поиск кода по хп проще и быстрее, чем по различным приложениям.

p.s. На большие таблицы, с которыми работает много пользователей\приложений, должен быть строго регламентированный доступ. Иначе будет жопа.
...
Рейтинг: 0 / 0
07.08.2018, 16:14
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633122
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
stenford 
CawaSPb 
Кстати, будет ли именно в Вами используемом ORM такая конструкция оттранслирована в предикат на уровне SQL, или будет производиться пост-фильтрация на уровне приложения?
конечно на уровне SQL, в этом весь смысл
Это, без всякого сомнения, правильно. Но при усложнении логики мы фактически получим реализацию SQL в выразительных средствах Host языка.
Это не всегда реализуемо (хотя и не всегда нужно), но всегда более громоздко.

Большой плюс для разработки - нахождение в рамках одного языка и одной парадигмы программирования.
Большой минус - в том же.

Кстати, добавьте в условие не "количество детей", а "количество несовершеннолетних детей" (что, согласитесь, вполне обычное бизнес-условие), и жизнь заиграет новыми красками.
...
Рейтинг: 0 / 0
07.08.2018, 16:24
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633134
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
Я в последнее время пришел к гибридному подходу. Для чтения данных ORM в большинстве случаев удобнее / проще, динамический поиск уже упоминали. А вот для сохранения данных, во избежание клиентских транзакций и шибко умных "оптимизаций" типа неожиданного кэширования / lazy write'a и проч., использую хранимки. Там можно и бизнес-правила быстро проверить, без перекачки данных туда-сюда, и какой надо try/catch написать, и TIL поменять, и хинты наложить, да все что угодно.

В результате с одной стороны сильно сокращается количество хранимок, с другой - весь ответственный код по-прежнему в БД, где легко отследить все зависимости, сделать при необходимости рефакторинг и прочее.

Еще бы они в EF нормальный интерфейс для вызова хранимок бы сделали, чтобы свои велосипеды не городить... эх.
...
Рейтинг: 0 / 0
07.08.2018, 16:34
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633142
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Ennor Tiegael 
Я в последнее время пришел к гибридному подходу. Для чтения данных ORM в большинстве случаев удобнее / проще, динамический поиск уже упоминали. А вот для сохранения данных, во избежание клиентских транзакций и шибко умных "оптимизаций" типа неожиданного кэширования / lazy write'a и проч., использую хранимки. Там можно и бизнес-правила быстро проверить, без перекачки данных туда-сюда, и какой надо try/catch написать, и TIL поменять, и хинты наложить, да все что угодно.

В результате с одной стороны сильно сокращается количество хранимок, с другой - весь ответственный код по-прежнему в БД, где легко отследить все зависимости, сделать при необходимости рефакторинг и прочее.

Еще бы они в EF нормальный интерфейс для вызова хранимок бы сделали, чтобы свои велосипеды не городить... эх.
Разумный подход!

p.s. А то, да, это мы еще только про select говорили... :)
...
Рейтинг: 0 / 0
07.08.2018, 16:41
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633250
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
982183 
alexeyvg 
Когда приложение разрабатывается и поддерживается много лет, так что сменились несколько поколений разработчиков, если ни один разработчик не представляет, как работает весь код системы, потому что его много, и т.д.
Бывает хуже.
Когда ни один аналитик не представляет структуру данных всей системы.
Отвечая только за её локальный модуль.
Не то, что бывает, а обязательно, для сложной системы.
Как же иначе, если она сложная?
stenford 
Megabyte 
Планы будут одинаковыми может быть в 80% случаев, но остальные 20 вам сделают проблем намного больше.

Кстати, в чем заключается лучшая поддерживаемость кода на клиенте? Только в том, что на фирме нет людей, хорошо знающих SQL, но знающих код клиента?

p.s. тысяча хранимок - это плохо, если можно обойтись 100, но должным образом параметризированных. Но если функциональность разная, то какая разница, сколько хранимок? Вы же не предъявляете претензии к объему клиентского кода...
Лучшая поддерживаемость заключается в том, что вместо тысяч хранимок с десятками параметров и 10-ти этажными case'ами (или вообще формирования динамического sql вручную и таинственных ошибок 'Invalid syntax near x symbol' в продакшене) у меня будет один единственный метод DAL'a IQuerable GetClients(), который разные методы будут вызывать с нужными параметрами и ОRM будет автоматически создавать правильный код.
Никаких проблем с планами не будет, а если и возникают - то решаются точно такими-же методами, как и при написании запросов вручную
Это всё так звучит...

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

Он будет предлагать нечто абсурдно звучащее, типа "храним код процедуры в базе, локальные переменные методов в полях, ну, при событии строим класс и отправляем джава-машине, эмулируя одновременно изменение значений переменных в полях...".

Вот для специалиста по реляционной алгебре, читать про ваши идеи моделирования операций реляционной алгебры на клиентском ЯП, сделав к базе только, по сути, интерфейс запроса отдельных записей, и надеясь, что ОРМ сам раскроет за вас бизнес-связь данных, и переделает ваше описание связей (на чуждом РСУБД языке) в язык запросов, так же странно, как вам читать про разработку Java-сервисов специалистом по СУБД.

Вот в некоторых случаях это прокатывает, если модель данных простая, и данных немного. И даже если что то там не срастётся, то не проблема, тысечекратное падение производительности никому неважно - 1 мс, или 1с, какая разница...
Но прокатывает не всегда.
...
Рейтинг: 0 / 0
07.08.2018, 17:53
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633265
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
alexeyvg 
stenford 
Лучшая поддерживаемость заключается в том, что вместо тысяч хранимок с десятками параметров и 10-ти этажными case'ами (или вообще формирования динамического sql вручную и таинственных ошибок 'Invalid syntax near x symbol' в продакшене) у меня будет один единственный метод DAL'a IQuerable GetClients(), который разные методы будут вызывать с нужными параметрами и ОRM будет автоматически создавать правильный код.
Никаких проблем с планами не будет, а если и возникают - то решаются точно такими-же методами, как и при написании запросов вручную
читать про ваши идеи моделирования операций реляционной алгебры на клиентском ЯП, сделав к базе только, по сути, интерфейс запроса отдельных записей, и надеясь, что ОРМ сам раскроет за вас бизнес-связь данных, и переделает ваше описание связей (на чуждом РСУБД языке) в язык запросов, так же странно, как вам читать про разработку Java-сервисов специалистом по СУБД.
Это я даже не начал говорить про главное, что БД часто разрабатывается не под приложение, а наоборот, приложения, всё новые и новые, год за годом, разрабатываются для БД. И тогда вот это отсутствие разработки БД как сущности проекта становится ещё более абсурдным.
...
Рейтинг: 0 / 0
07.08.2018, 18:00
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633293
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
sti 
alexeyvg 
Я уверен, что нормальный SQL разработчик не спроектировал бы такую модель данных, и написал бы такой запрос.

Зло ОРМ не в том, что там делается какой то кривой код условий запросов, например, с синтаксическими ошибками (с чего бы?), а в том, что разработчики не выделяют работу с данными как слой системы, требующий специалиста с соответствующей квалификацией. Поэтому получаются такие вот страшные поделия.
Второй недостаток, вытекающий из первого - отсутствие отдельного слоя не позволяет полноценно контролировать работу с СУДБ, теми же самыми узкими специалистами.

И если это прекрасно работает для приложения-записной книжки, то для более сложных и нагруженных систем будет проблемой, делая их неработоспособными в реальной жизни. Когда приложение разрабатывается и поддерживается много лет, так что сменились несколько поколений разработчиков, если ни один разработчик не представляет, как работает весь код системы, потому что его много, и т.д.
alexeyvg, пример был мой, но ваш ответ в точку! Проблема не в запросе как таковом, а в модели данных. И действительно, давайте запихаем всё в одну таблицу и никаких проблем :-)
Именно, в модели данных, и в последнем ответе я опять пишу про это, и сейчас ещё раз напишу.
stenford 
есть к примеру таблица с клиентами Client (Name, Surname, DOB и еще 20 полей). Одной подсистеме надо клиентов отбирать по имени + фамилии, другой - по дате рождения, третьей - по адресу. С хранимками у вас 2 варианта - иметь 3 хранимки (с такими замечательными именами как GetClientsByNameAndSurname), либо иметь одну хранимку с десятком параметров и лестницей из case'ов внутри (либо ручным динамическим sql).
С ОRM будет один метод DAL IQuerable GetClients(). Вызывающие подсистемы просто вызовут его как GetClients().Where(c => c.Name == 'Alex' && Surname == 'Ivanov'). Все остальное сделает ОRM.
...
А мне в буквальном смысле слова не надо будет ничего делать. Подсистема просто вызовет мой метод как GetClients().Where(c => c.Kids > 0)
Вот именно, у программиста и не будет позывов подумать над моделью данных, он просто не выделяет её как какую то существенную часть проекта.
А иногда это нужно сделать, поменять модель данных. Или, например, сделать матвьюху, что бы запрос из таблицы на самом деле не обращался к таблице, а брал сохранённые агрегированные значения.

Ну и делать тыщу процедур для поиска по имени, по имени и фамилии, и т.д., тоже не самая удачная идея. Для специалиста по Java или C++ такое решение очевидно, но не для специалиста по СУБД.
Вы бы, проектируя классы на C#, сделали бы тыщу методов "с такими замечательными именами как GetClientsByNameAndSurname", или придумали бы что то получше?
...
Рейтинг: 0 / 0
07.08.2018, 18:15
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633350
jbond81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jbond81
Участник
Фёдоров 
Sergunka 
большинство ДБА перешли либо в noSQL типо Кассандра, Биг Дата, МонгоДБ, Спарк и тд
?!?!?!?! А куда же подевались миллионы баз на SQL и Oracle? Видимо, сами незаметно перевелись на Кассандру, где их уже ждут не дождутся большинство ДБА...
С каких это пор можно на одном только знании sql от оракла куда то уехать? Шарп и/или Ява плюс веб с APEX и ты стоишь 60К минимум
...
Рейтинг: 0 / 0
07.08.2018, 18:49
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633367
jbond81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jbond81
Участник
gpu 
stenford 
да, ориентированные на данные системы действительно исключение. Там, где логика полностью завязана на данных, по определению нет никаких ORM, масса ad hoc запросов и отчетов - то такие системы жизнеспособны только с дба. Но их относительно немного, гораздо чаще под их видом предоставляют систему, написанную в стиле конца 90-х, с логикой в хранимках, триггерами и прочими "аттрибутами". К счастью этот кошмар остался в основном только в легаси
Стесняюсь спросить, а в чем криминал в логике в хранимках?
Стоимость внесения изменений стремится к бесконечности.
...
Рейтинг: 0 / 0
07.08.2018, 19:02
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633381
Фотография Wizandr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Wizandr
Участник
jbond81 
gpu 
пропущено...

Стесняюсь спросить, а в чем криминал в логике в хранимках?
Стоимость внесения изменений стремится к бесконечности.
дык наоборот же
открыл хранимку внес изменения
даже деплоить ничего не нужно :)
...
Рейтинг: 0 / 0
07.08.2018, 19:14
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633392
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Wizandr 
jbond81 
пропущено...

Стоимость внесения изменений стремится к бесконечности.
дык наоборот же
открыл хранимку внес изменения
даже деплоить ничего не нужно :)
Ага, чуть изменить логику поиска, и уже "нууу, это же нужно менять концепцию классов" :-)
...
Рейтинг: 0 / 0
07.08.2018, 19:20
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633548
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
stenford 
CawaSPb 
Кстати, будет ли именно в Вами используемом ORM такая конструкция оттранслирована в предикат на уровне SQL, или будет производиться пост-фильтрация на уровне приложения?
конечно на уровне SQL, в этом весь смысл
Только если какой-нибудь "фанат орм" не имплементирует GetClients() как
Код: C#
1.
context.Clients.ToList()
:))
...
Рейтинг: 0 / 0
07.08.2018, 22:40
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633556
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
Wizandr 
jbond81 
пропущено...

Стоимость внесения изменений стремится к бесконечности.
дык наоборот же
открыл хранимку внес изменения
даже деплоить ничего не нужно :)
Кстати да, когда нет возможности приложение в Любой момент пропатчить, то альтернативы хранимкам нет
...
Рейтинг: 0 / 0
07.08.2018, 22:49
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633557
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
CawaSPb 
Кстати, добавьте в условие не "количество детей", а "количество несовершеннолетних детей" (что, согласитесь, вполне обычное бизнес-условие), и жизнь заиграет новыми красками.
Проще простого
...
Рейтинг: 0 / 0
07.08.2018, 22:51
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633561
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
Megabyte 
А если разобрать другую ситуацию: таблица, например, 100млн транзакций. Будешь ли ты обращаться к ней по какому угодно фильтру то, на выбор:
1) будешь жрать ресурсы на скан таблицы и мешать другим пользователям, если не положишь систему в целом.
2) натыкаешь индексов на все возможные поля и поимеешь производительность на вставку\апдейт\удаление записи.
Ты хотел сказать потеряешь?
...
Рейтинг: 0 / 0
07.08.2018, 22:54
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633567
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
yabs 
Megabyte 
А если разобрать другую ситуацию: таблица, например, 100млн транзакций. Будешь ли ты обращаться к ней по какому угодно фильтру то, на выбор:
1) будешь жрать ресурсы на скан таблицы и мешать другим пользователям, если не положишь систему в целом.
2) натыкаешь индексов на все возможные поля и поимеешь производительность на вставку\апдейт\удаление записи.
Ты хотел сказать потеряешь?
Таки да.
...
Рейтинг: 0 / 0
07.08.2018, 23:02
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633676
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
Megabyte 
Когда клиентов в таблице 100-1000, то да, код ОРМ будет немного проще. Я согласен, что можно и ОРМ заюзать.

А если разобрать другую ситуацию: таблица, например, 100млн транзакций. Будешь ли ты обращаться к ней по какому угодно фильтру то, на выбор:
1) будешь жрать ресурсы на скан таблицы и мешать другим пользователям, если не положишь систему в целом.
2) натыкаешь индексов на все возможные поля и поимеешь производительность на вставку\апдейт\удаление записи.

И вот какой-то программист, который вдруг захочет по этой таблице отфильтровать по какому-то второстепенному полю, запустит внезапно скан всей таблицы, будет веселуха.

С хп такой финт ушами не пройдет, надо будет сначала произвести доработку процы, внедрить параметр, или сделать новую процу.
Но на сервере можно же и разграничить доступ в том числе и для программистов, чтоб не делали всякую хрень без проверки ДБА. :)
то, что для хранимки потребуется больше работы (новый параметр или новая хранимка) никак не обезопасит систему. Если разработчик запулил запрос по полю без индексов - то это проблема безотносительна хранимок или ORM, это вина разработчика, и только его. В случае хранимок никакой ДБА его не спасет - на практике они никогда не проверяют код перед коммитом в систему, да и бессмысленно это будет в большинстве случаев, ДБА тоже легко может пропустить такую ошибку если ему свалить на код ревью десятки хранимок в день сделанные разработчиками. Такие проблемы решаются не привлечением ДБА, а элементарым нагрузочным тестированием, скан таблицы мгновенно всплывет в тесте и будет зафиксен. На самом деле даже раньше т.к. в грамотно поставленном процессе разработчик до коммита сначала проверит что за план у него сгенерился и словит скан даже на небольшой таблице
...
Рейтинг: 0 / 0
08.08.2018, 02:20
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633677
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
CawaSPb 
Это, без всякого сомнения, правильно. Но при усложнении логики мы фактически получим реализацию SQL в выразительных средствах Host языка.
Это не всегда реализуемо (хотя и не всегда нужно), но всегда более громоздко.

Кстати, добавьте в условие не "количество детей", а "количество несовершеннолетних детей" (что, согласитесь, вполне обычное бизнес-условие), и жизнь заиграет новыми красками.
Linq действительно более ограниченный чем sql, но ему и не надо быть сильно продвинутым, задача ORM - получить бизнес-сущности для работы в бизнес-слое, там обычно не требуется навороченных конструкций т.к. сама бизнес-логика будет работать после. Вместо хранимки с сотнями строк, функций и логики будет несколько несложных запросов с которыми потом работает бизнес-слой на языке куда более подходящем для этой работы.
Отчеты по-прежнему в хранимках
...
Рейтинг: 0 / 0
08.08.2018, 02:26
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633678
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
alexeyvg 
Вот для специалиста по реляционной алгебре, читать про ваши идеи моделирования операций реляционной алгебры на клиентском ЯП, сделав к базе только, по сути, интерфейс запроса отдельных записей, и надеясь, что ОРМ сам раскроет за вас бизнес-связь данных, и переделает ваше описание связей (на чуждом РСУБД языке) в язык запросов, так же странно, как вам читать про разработку Java-сервисов специалистом по СУБД.
ничего странного Linq не делает, он по-сути напоминает тот-же sql, где есть и джойны, и условия и группировки и прочее. Зная sql, написать linq запрос не составляет особого труда
...
Рейтинг: 0 / 0
08.08.2018, 02:32
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633679
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
alexeyvg 
А иногда это нужно сделать, поменять модель данных. Или, например, сделать матвьюху, что бы запрос из таблицы на самом деле не обращался к таблице, а брал сохранённые агрегированные значения.
нет никаких проблем сделать запрос к матвьюхе вместо таблицы.
alexeyvg 
Вы бы, проектируя классы на C#, сделали бы тыщу методов "с такими замечательными именами как GetClientsByNameAndSurname", или придумали бы что то получше?
конечно придумали-бы что-то получше, ORM называется. А вот у вас с хранимками других путей собственно и нет. Я даже не говорю про последующую поддержку, когда имея тысячи хранимок с похожими запросами меняется структура таблицы и начинается веселуха с выявлением где что надо менять.
...
Рейтинг: 0 / 0
08.08.2018, 02:38
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633682
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
yabs 
Кстати да, когда нет возможности приложение в Любой момент пропатчить, то альтернативы хранимкам нет
нет принципиальной разницы между запуском скрипта на базу или переустановкой API на аппсервере. С той разницей что переустановка куда безопаснее т.к. обычно сначала тестируется и обновляется номер версии. Горячие замены напрямую в базе признак бардака в организации, когда ДБА на продакшене в режиме ошпаренной кошки фиксит баги не тестируя свои изменения и внося новые баги
...
Рейтинг: 0 / 0
08.08.2018, 02:53
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633759
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
stenford,

В кто говорил про аппсервер?
...
Рейтинг: 0 / 0
08.08.2018, 08:24
| Ответить | Цитировать | Написать  
25 сообщений из 375, страница 11 из 15
  11  все
Форумы / Наши за рубежом [закрыт для гостей] / Что происходит на рынке DB вакансий в ЕС?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=7&msg=21633015&tid=1297162]:
 0ms
get settings:
 19ms
get forum list:
 5ms
check forum access:
 1ms
check topic access:
 1ms
track hit:
 60ms
get topic data:
 2ms
get forum data:
 1ms
get page messages:
 425ms
get tp. blocked users:
 0ms
others: 293ms
total:  807ms
созд. / загр.: 807ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]