Здравствуйте, QrystaL, Вы писали:
QL>Такой вопрос — как реализовать наследование Table Per Class? (Я так понимаю, поддерживается только Table Per Hierarchy, и соответственно какие-то workarounds нужны...)
It appears that MS has deleted the bug on Microsoft Connect.
...
I blogged about this in January 2010, and the bug was opened on 3/17/2010. MS didn’t respond until 6/29/2010, when they said:
... Will keep you posted as we find out more, however. Hope this helps. Entity Framework Team
Apparently “keep you posted” means “we’ll delete your posts”
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, QrystaL, Вы писали:
QL>>Такой вопрос — как реализовать наследование Table Per Class? (Я так понимаю, поддерживается только Table Per Hierarchy, и соответственно какие-то workarounds нужны...)
S>Неа, table per type есть, но такой, что лучше бы не было
Интересно )))
Я наверное неправильно сформулировал — вопрос был про LinqToSql/BLToolkit =)
Здравствуйте, Ringin, Вы писали:
R>... задача стояла работать с базой через ORM, и я остановился на Entity Framework. R>Выскажите пожалуйста свои мнения!
Мнение: Вы — не очень умный человек. Техническая интуиция, при виде бесконечный воплей в тырнете "а как мне сделать ХХХ в EF" или "почему EF делает XXX, а мне нужно YYY", должна была сразу завопить: "Нет! Только если мне доплатит мелкософт!".
Для себя пока лучше BLToolkit ничего не нашёл. Хотя и не искал особо, если честно: зачем, если он и так практически идеально вписывается в код? Прост как мухобойка, быстр как бегущий за пивом и ненавязчив как Медведев — берёшь свои объекты и одной строкой они уже в БД! По-моему, те, кто залезли по гланды в EF, никогда не пробовали, насколько прост BLT — им просто некогда решать бизнес задачи и пробовать новое — носятся по форумам с проблемами, навешанными мелкософтом и думают, что "раз от мелкософта — значит круто!".
Здравствуйте, IT, Вы писали:
IT>Я как раз не предлагаю использовать EF. Сам я его внимательно поизучал, и именно по этой причине никогда в реальных проектах не использовал. Кроме EF есть другие вполне приемлемые решения.
... R>А вот надо мне например вывести пользователю все таблицы базы данных, прочитать констрейнты и показать связи, как это сделать?
INFORMATION_SHEMA ?
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
Здравствуйте, rFLY, Вы писали:
IT>>Я как раз не предлагаю использовать EF. Сам я его внимательно поизучал, и именно по этой причине никогда в реальных проектах не использовал. Кроме EF есть другие вполне приемлемые решения. FLY>Например?
Здравствуйте, Кондраций, Вы писали:
R>>А вот надо мне например вывести пользователю все таблицы базы данных, прочитать констрейнты и показать связи, как это сделать? К>INFORMATION_SHEMA ?
Крайне геморойное занятие, особенно учитывая специфику разных БД. В linq2db реализован SchemaProvider, одним вызовом можно получить всю информацию.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ringin, Вы писали:
R>Разбирался на днях с Entity Framework, точнее сказать задача стояла работать с базой через ORM, и я остановился на Entity Framework. R>У меня сложилось очень двоякое впечатление. Что-то хорошо, а что-то, что можно сделать совершенно простым запросом к бд, через entity framework просто так не сделаешь.
R>Выскажите пожалуйста свои мнения!
Здравствуйте, Ringin, Вы писали:
R>Разбирался на днях с Entity Framework, точнее сказать задача стояла работать с базой через ORM, и я остановился на Entity Framework. R>У меня сложилось очень двоякое впечатление. Что-то хорошо, а что-то, что можно сделать совершенно простым запросом к бд, через entity framework просто так не сделаешь.
R>Выскажите пожалуйста свои мнения!
Асилил ~2/3 мнений.
Я так понял:
1. EF — отстой
2. LINQ — типа рулит
<далее — изделия советских инженеров?>
3. BLT — ваще рулит. Правда на днях я на него ругался, когда пытался запустить Януса на FB. Траблы с квотированными именами. Проблему я ниасилил.
4. LINQ2DB — спасение человечества(?)
---
Я пока не знаю — "кто все эти люди".
Но через пару месяцев надо будет выбирать следующее направление развития для своих игрушек для взаимодействия с FB/IB.
Стоит начать с поддержки LINQ?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
A>>[/c#] A>>Вот как ORM должен сформировать два запроса sql, чтобы выбрать всех рабочих (коллекцию Employee включая в каждый коллекцию detailсов Project) имя у которых начинается на символ "А"? S>"Имя у которых" — это имя проекта? Для проекта очевидно, для рабочих — S>
S> SELECT E.* FROM Employee E WHERE EXISTS (SELECT * FROM Project P WHERE P.Employee_ID = E.ID AND P.Name LIKE '%A%')
S>
S>?
S>Если имя — это имя сотрудника, то (для сотрудников очевидно): S>
S> SELECT P.* FROM Project P INNER JOIN Employee E ON P.Employee_ID = E.ID WHERE E.Name LIKE '%A%'
S>
S>Да, при выборке по нескольким спецификациям сложность запросов возрастёт, но это окупится тем, что в результате не будет nMaster * nDetail_1 * nDetail_2 строк S> *(nDetail_1(2) — среднее число записей детейлов на одного мастера).
зато будут такие артефакты
select top 10000 GETDATE(), * from sometable
select top 10000 GETDATE(), * from sometable
Здравствуйте, SoLame, Вы писали:
S>>Да, при выборке по нескольким спецификациям сложность запросов возрастёт, но это окупится тем, что в результате не будет nMaster * nDetail_1 * nDetail_2 строк S>> *(nDetail_1(2) — среднее число записей детейлов на одного мастера).
SL>зато будут такие артефакты
select top 10000 GETDATE(), * from sometable
select top 10000 GETDATE(), * from sometable
Н
S>>>Да, при выборке по нескольким спецификациям сложность запросов возрастёт, но это окупится тем, что в результате не будет nMaster * nDetail_1 * nDetail_2 строк S>>> *(nDetail_1(2) — среднее число записей детейлов на одного мастера).
SL>>зато будут такие артефакты
S>
S>select top 10000 GETDATE(), * from sometable
S>select top 10000 GETDATE(), * from sometable
S>
S>Зачем? Не, без сарказма — откуда они возьмутся?
например от туда
create view sometable
as
select GETDATE() some_column
--далее всякие джойны по вкусу.
Здравствуйте, SoLame, Вы писали:
S>>Зачем? Не, без сарказма — откуда они возьмутся? SL>например от туда
create view sometable
as
select GETDATE() some_column
--далее всякие джойны по вкусу.
А давайте помедленнее, я за вами не успеваю
Речь шла про подход EF (один запрос вытаскивания для мастера и спецификаций) vs более логичный "1 запрос на каждую таблицу". Итак, откуда возьмётся описанная вами проблема, почему она не возникнет с подходом EF и собственно в чём она заключается?
Особенно с учётом того, что:
1. С вероятноcтью стремящейся к 1 GETDATE() не будет использоваться в запросах (кроме как для основной выборки) и будет выброшен оптимизатором.
2. Использование nondeterministic функций в view — не самая лучшая идея, проблема уже в ней, а не в том как дальше делать запросы.
Здравствуйте, Sinix, Вы писали:
S>Речь шла про подход EF (один запрос вытаскивания для мастера и спецификаций) vs более логичный "1 запрос на каждую таблицу". Итак, откуда возьмётся описанная вами проблема, почему она не возникнет с подходом EF и собственно в чём она заключается?
S>Особенно с учётом того, что: S>1. С вероятноcтью стремящейся к 1 GETDATE() не будет использоваться в запросах (кроме как для основной выборки) и будет выброшен оптимизатором. S>2. Использование nondeterministic функций в view — не самая лучшая идея, проблема уже в ней, а не в том как дальше делать запросы.
"откуда". Мы незнаем. EF у нас тулза-всёмогутер, которая должна покрывать все сценарии использования.
"почему". Потому что EF выполняет sql запрос, именно так, как просил пользователь. одним запросом — значит одним. пользователь напишет два — значит два.
1,2 мы этого не знаем. у нас тулза-всёмогутер. и с каким базами он будет работать — разработчикам не ведомо. кроме GetDate() есть другие функции,
и функции которые написал пользователь на их основе...
а так же вы забываете про уровни изоляции транзакций...
The EF code base has a long history, going back to the WinFS days, with parts of the code base being 10+ years old. [...] EF7 will be a lightweight and extensible version of Entity Framework that just pulls forward the commonly used features. In addition, we’ll be able to include some commonly requested features that would have been difficult to implement in the existing code base, but can be included from the start in EF7.
QL>The EF code base has a long history, going back to the WinFS days, with parts of the code base being 10+ years old. [...] EF7 will be a lightweight and extensible version of Entity Framework that just pulls forward the commonly used features. In addition, we’ll be able to include some commonly requested features that would have been difficult to implement in the existing code base, but can be included from the start in EF7.
Техническая интуиция, при виде бесконечный воплей в тырнете "а как мне сделать ХХХ в EF" или "почему EF делает XXX, а мне нужно YYY", должна была сразу завопить: "Нет! Только если мне доплатит мелкософт!".
Если нам не помогут, то мы тоже никого не пощадим.
