Вот на днях решил опробовать LINQ to SQL в VS 2008...
Создал простенькую базу для теста.
Основная цель была проверка маппинга на хранимые процедуры и корректной реализации/настройки наследования.
Не знаю как для кого, но для меня теоритически существует два нормальных вида реализции наследования в БД (хотя многие не любят применять этот термин относительно БД).
1 — это реализация наследования в виде связи 1-к-1 (атрибуты родительского класса не дублируются в производных)
2 — дублирование атрибутов родительского класса в производных.
Часто с успехом мне удается комбинировать эти два подхода в целях оптимизации работы БД.
Другие подходы, по типу "столбец-идентификатор типа" и спихивание всех атрибутов всех типов в одну таблицу считаю вариациями плохого проектирования или анализа, EAV — отдельная тема.
Маппинг на хп действительно оказался возможным, что очень порадовало, при этом настройка маппинга сделана удобной и гибкой.
Однако, что касается наследования — полный отстой.
То что нам предлагается в этом плане — это Single-table inheritance.
Вы настраиваете base-class, указывая свойство-идентификатор типа на основе которого LINQ определяет какой тип объекта будет создан для каждого экземпляра при запросе всей коллекции базового типа. При этом, похоже, что на уровне БД у вас нет возможности разнести производные классы по таблицам, т.е. все атрибуты всех классов должны лежать в одной таблице(или же должна использоваться view), а на уровне dbml-разметки определяется какие атрибуты к какому классу относятся.
Для меня, например, это полный бред.
Потом, в коде нет возможности поместить экземпляр производного типа в свою же типизированную коллекцию. Вы можете поместить экземпляр производного типа только в коллекцию базового типа. Коллекции для производных типов просто не генерятся. Т.е. нет возможности сделать DataContext.DerivedClassList.InsertOnSubmit(derivedInstance);
Возможно только DataContext.BaseClassList.InsertOnSubmit(derivedInstance); но при этом, когда происходит SubmitChanges() производится маппинг на методы (хп) базового типа.
Вот что по этому поводу написано в MSDN: The Object Relational Designer (O/R Designer) supports the concept of single-table inheritance as it is often implemented in relational systems. In single-table inheritance, there is a single database table that contains fields for both parent information and child information.
Это где это они такой "often implemented" нашли ? Индусы что ли замучали?
При этом multi-table inheritance они обещали сделать в релизе, еще когда появился августовский CTP...
Вообщем, как ORM продукт для меня оказался достаточно сыроват. Посмотрим, может быть что то измениться в будущем, а пока в сторону, обойдемся. Да и прочие поставщики субд (oracle...) смотрю, как то без особой эйфории отнеслись к linq, не спешат они делать реализации его под свои субд...
Здравствуйте, снежок, Вы писали:
С>Вообщем, как ORM продукт для меня оказался достаточно сыроват. Посмотрим, может быть что то измениться в будущем, а пока в сторону, обойдемся. Да и прочие поставщики субд (oracle...) смотрю, как то без особой эйфории отнеслись к linq, не спешат они делать реализации его под свои субд...
LINQ to SQL не позиционируется как полноценный ORM framework.
Дождитесь выхода ADO.NET Entity Framework в феврале. Там будет все что вам необходимо (в частности по маппингу и наследованию все ваши вопросы решаются там элементарно).
S>LINQ to SQL не позиционируется как полноценный ORM framework. S>Дождитесь выхода ADO.NET Entity Framework в феврале. Там будет все что вам необходимо (в частности по маппингу и наследованию все ваши вопросы решаются там элементарно).
Очень надеюсь что решатся.
Ну а как тогда позиционируется LINQ to SQL? Полноценным маппинг-хелпером его тоже не назовешь...
V>ORM и query-helper — это из разных опер вещи.
vdimas, я в курсе
Просто не понятно теперь становится вообще место LINQ to SQL.
Т.е. это сильно урезанная версия EDM для экспериментов на досуге?
С>Просто не понятно теперь становится вообще место LINQ to SQL.
Место простое — реализация провайдера, чтобы ты сам его не писал.
С>Т.е. это сильно урезанная версия EDM для экспериментов на досуге?
Да вот еще. Для нашей мини-ORM системы подобный провайдер позволит выкинуть самописный SQL-генератор и немного улучшить код, где мы генерируем объекты-запросы. Так же позволит выкинуть приличный код по маппингу, т.к. LINQ в этом плане тоже нехило помогает.
Здравствуйте, снежок, Вы писали:
С>Просто не понятно теперь становится вообще место LINQ to SQL. С>Т.е. это сильно урезанная версия EDM для экспериментов на досуге?
Есть мнение, что ООП с его догмами подходит для хранения и обработки данных несколько хуже чем SQL-РСУБД. LINQ to SQL — это средство не использоват мапинг, а работать с массивами данных напрямую. Объекты зедесь не более чем средство представления данных из БД. Именно по этому были введены анонимные типы. Они вообще прямое воплощение кортежа из реляционной логики.
ЗЫ
Не спеши возмущаться. Твое сознание зашорено теми догмами которые впишивали в него индустриальные проповедники. Возможно когда-то ты прицдешь к выводу, что O/R-маперы шаг в не верном направлении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не спеши возмущаться. Твое сознание зашорено теми догмами которые впишивали в него индустриальные проповедники. Возможно когда-то ты прицдешь к выводу, что O/R-маперы шаг в не верном направлении.
С>Другие подходы, по типу "столбец-идентификатор типа" и спихивание всех атрибутов всех типов в одну таблицу считаю вариациями плохого проектирования или анализа
Ну, обоснуй что-ли для ясности
Заодно прикинь стоимость соединения таблиц, если, скажем, у тебя в иерархии пару миллионов записей, а отличающихся в потомках свойств — раз два и обчелся.
Здравствуйте, Igor Trofimov, Вы писали:
С>>Другие подходы, по типу "столбец-идентификатор типа" и спихивание всех атрибутов всех типов в одну таблицу считаю вариациями плохого проектирования или анализа
iT>Ну, обоснуй что-ли для ясности
Ванек Бодягин (IB) вон минусы ставит и ничего обосновывать или рассказать что то полезное (раз уж он такая звезда в LINQ) не стремиться iT>Заодно прикинь стоимость соединения таблиц, если, скажем, у тебя в иерархии пару миллионов записей, а отличающихся в потомках свойств — раз два и обчелся.
Стоимость соединения я прикидываю на реальных данных в ходе внедрения или эксплуатации.
И если оно, соединение, становится слишком дорогим, то я легко рефакторю "тяжелые" таблицы ко второму варианту реализации наследования, когда атрибуты предка дублируются в атрибутах потомка. При этом связь 1-к-1 исчезает(удаляется). И так как работа с таблицами инкапсулирована в хп, то никакие слои кроме CRUD SPs и DB этот рефакторинг не задевает. Вообще эта задача может ложиться на администратора БД/тех. специалиста по обслуживанию, если четко прописать ему roadmap для подобных случаев.
На первоначальном этапе анализа и проектирования я никогда не заменяю наследование на атрибут-признак типа, так как с большой вероятностью на этом этапе может что то ускользнуть от твоего взгляда и при этом легко допустить ошибку проектирования.
Я всегда смогу вернуться к рефакторингу в направлении создания атрибута-признака типа на завершающих этапах, если это решение действительно окажется удовлетворительным. Яркий пример когда введение атрибута-признака типа очень часто является ошибкой — это "Физические лица и Юридические лица". Хороший пример когда стоит ввести такой атрибут — это "Балансовый и Забалансовый счет в бухучете" т.к. довольно сложно придумать как еще эти подтипы могут быть расширены.
А рассуждая так, что в потомках отличающихся свойств раз два и обчелся, недолго дойти и до решения когда всю базу можно уложить в одну таблицу. Хотя я конечно же уверен что к такому маразму ты никогда не стремился
P/S/
Кстати, нашел блог где достаточно хорошо расставлены точки над i и объясняется по поводу места Linq to sql и EDF: здесь
VD>Есть мнение, что ООП с его догмами подходит для хранения и обработки данных несколько хуже чем SQL-РСУБД. LINQ to SQL — это средство не использоват мапинг, а работать с массивами данных напрямую. Объекты зедесь не более чем средство представления данных из БД. VD>ЗЫ VD>Не спеши возмущаться. Твое сознание зашорено теми догмами которые впишивали в него индустриальные проповедники. Возможно когда-то ты прицдешь к выводу, что O/R-маперы шаг в не верном направлении.
Скорее тут не направление может оказаться неправильным, а применение.
Просто существуют data-ориентированные системы/решение и решения где тяжеловато обойтись без разветвленных бизнес-классов. Вот, видимо, LINQ to SQL позиционируется как решение для data-ориентированных систем. И хотя EDF полностью покрывает по возможностям LINQ to SQL — это весьма далекие друг от друга продукты.
Ну и мои 5 копеек. Сразу, чтоб не флеймить. Сам по себе LINQ — забавная идея. Но вот реализация...
Она дико сырая. Безумно раздражает, что вместо того, чтобы работать с сиквелом, который я знаю и понимаю, я должен работать с какой-то финтифлюшкой, которая изображает из себя сиквел, как его видят разработчики финтифлюшки. Плохо видят кстати. Меня задолбало пытаться написать LINQ-запрос так, чтоб он хотя бы примерно соответствовал тому, что должно быть и угадывать, как поведёт себя SelectMany в сочетании с GroupBy и GroupJoin (да, кстати, Left Join'a нет. Потомучта.). Задолбало разбираться, почему я должен править что-то в xml-х кишках этого чудо-монстра, чтобы наконец заработали хранимые процедуры, а потом материться и переписывать параметризованные функции на вьюхи, чтобды эта падла нормально загружала details'ы.
В общем жопа всё это. Впрочем, не меньшая, чем EF. Последнее вообще, по-моему, бред полный, ибо трактуется как средство для выноса концептуальной модели на сторону клиента. Афигеть, да? А сиквел у нас чем должен заниматься? Байтики хранить? А теперь учтите, что у нас не одно приложение базу юзает. И каждое должно видеть эту базу по-своему, и не лезть куда не положено, потому что в противном случае шеф собственноручно глубоко проинсталлирует в меня весь сервер. У каждого приложения должна быть своя концептуальная модель, да?)))
В общем от лукавого всё это...
Ндя. Обещал же. 5 копеек про LINQ for SQL.
1. Отсутствие отсоединённого режима работы.
Я до сих пор не могу понять, почему либо я использую SqlQuery<T> (или как его там...) и терплю непрекращаюшиеся обращения к серверу на каждый чих,
либо пытаюсь использовать EaferLoad с копированием загруженных элементов типа .ToBindingList() и натыкаюсь на весёлые грабли... Потому что EagerLoad тоже через попу работает))) Самое большее, что с его помощью можно добиться — чтобы загружались дети при обращении к родителю. В результате, если у вас 15 родительских записей, вам потребуется обратиться к серверу всего 15 раз. Мило, да?)
Если интересно — _тынц_ на пост из блога OakLeaf Systems (там есть ещё много таких граблей... читайте и обрящете дао), тынц августовский, но те же грабли наблюдаются и на релизе.
Да, многие-ко-многим — это тоже та ещё пестня... Но про это я рассказывать не буду — не хочу портить очучения.
2. Производительность. На эту тему даже рыдать не хочется. Я не могу понять, почему жалкие полтыщи master/details строк должны загружаться по три-пять секунд? Аналогичный штук с датаадаптером на порядок шустрее.
3. Lazy load. Ну вот раздражает меня тот факт, что результатом любого запроса могут быть устаревшие данные (не забываем, что все сущности весьма весело кэшируются внутри контекста). Даже если мне надо будет показывать лишь часть данных, я предпочту постраничную выборку. Потому что буду уверен, что все данные согласованы. И не буду гадать, сколько времени назад и что загрузилось.
4. Невозможность сериализации данных. Точнее так. Сериализовать их можно. А вот восстановить и определить какие данные надо вставить в БД, а какие не изменялись — хрен те. Официальный совет: восстанавливайте оригинальные версии и вносите все изменения заново. Опупеть, да?
5. Убогий сгенеренный код. Если начальство увидит, что код в продакшне обращается к серверу вот так (это для одного (!) родителя):
exec sp_executesql N'SELECT [t0].[OrderID], [t0].[CustomerID],
[t0].[EmployeeID], [t0].[OrderDate], [t0].[RequiredDate],
[t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[ShipName],
[t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion],
[t0].[ShipPostalCode], [t0].[ShipCountry], [t1].[OrderID] AS [OrderID2],
[t1].[ProductID], [t1].[UnitPrice], [t1].[Quantity], [t1].[Discount], (
SELECT COUNT(*)
FROM [dbo].[Order Details] AS [t2]
WHERE [t2].[OrderID] = [t0].[OrderID]
) AS [count]
FROM [dbo].[Orders] AS [t0]
LEFT OUTER JOIN [dbo].[Order Details] AS [t1]
ON [t1].[OrderID] = [t0].[OrderID]
WHERE [t0].[CustomerID] = @x1
ORDER BY [t0].[OrderID], [t1].[ProductID]',N'@x1 nchar(5)',@x1=N'ALFKI'
или не дай бог вот так (типа EagerLoad, как добиться — см здесь):
SELECT COUNT(*) AS [value]
FROM [dbo].[Orders] AS [t0]
LEFT OUTER JOIN [dbo].[Customers] AS [t1]
ON [t1].[CustomerID] = [t0].[CustomerID]
LEFT OUTER JOIN [dbo].[Employees] AS [t2]
ON [t2].[EmployeeID] = [t0].[EmployeeID]
LEFT OUTER JOIN [dbo].[Shippers] AS [t3] ON [t3].[ShipperID] = [t0].[ShipVia]
exec sp_executesql N'SELECT TOP 15 [t7].[OrderID], [t7].[CustomerID],
[t7].[EmployeeID], [t7].[OrderDate], [t7].[RequiredDate],
[t7].[ShippedDate], [t7].[ShipVia], [t7].[Freight], [t7].[ShipName],
[t7].[ShipAddress], [t7].[ShipCity], [t7].[ShipRegion],
[t7].[ShipPostalCode], [t7].[ShipCountry], [t7].[test],
[t7].[CustomerID2], [t7].[CompanyName], [t7].[ContactName],
[t7].[ContactTitle], [t7].[Address], [t7].[City], [t7].[Region],
[t7].[PostalCode], [t7].[Country], [t7].[Phone], [t7].[Fax], [t7].[test2],
[t7].[EmployeeID2], [t7].[LastName], [t7].[FirstName], [t7].[Title],
[t7].[TitleOfCourtesy], [t7].[BirthDate], [t7].[HireDate],
[t7].[Address2], [t7].[City2], [t7].[Region2], [t7].[PostalCode2],
[t7].[Country2], [t7].[HomePhone], [t7].[Extension], [t7].[Notes],
[t7].[ReportsTo], [t7].[test3], [t7].[ShipperID], [t7].[CompanyName2],
[t7].[Phone2]
FROM (
SELECT ROW_NUMBER() OVER (ORDER BY [t0].[OrderID], [t0].[CustomerID],
[t0].[EmployeeID], [t0].[OrderDate], [t0].[RequiredDate],
[t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[ShipName],
[t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion],
[t0].[ShipPostalCode], [t0].[ShipCountry], [t2].[test],
[t2].[CustomerID], [t2].[CompanyName], [t2].[ContactName],
[t2].[ContactTitle], [t2].[Address], [t2].[City], [t2].[Region],
[t2].[PostalCode], [t2].[Country], [t2].[Phone], [t2].[Fax],
[t4].[test], [t4].[EmployeeID], [t4].[LastName], [t4].[FirstName],
[t4].[Title], [t4].[TitleOfCourtesy], [t4].[BirthDate], [t4].[HireDate],
[t4].[Address], [t4].[City], [t4].[Region], [t4].[PostalCode],
[t4].[Country], [t4].[HomePhone], [t4].[Extension], [t4].[ReportsTo],
[t6].[test], [t6].[ShipperID], [t6].[CompanyName], [t6].[Phone])
AS [ROW_NUMBER],
[t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate],
[t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight],
[t0].[ShipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion],
[t0].[ShipPostalCode], [t0].[ShipCountry], [t2].[test],
[t2].[CustomerID] AS [CustomerID2], [t2].[CompanyName],
[t2].[ContactName], [t2].[ContactTitle], [t2].[Address], [t2].[City],
[t2].[Region], [t2].[PostalCode], [t2].[Country], [t2].[Phone],
[t2].[Fax], [t4].[test] AS [test2], [t4].[EmployeeID] AS [EmployeeID2],
[t4].[LastName], [t4].[FirstName], [t4].[Title], [t4].[TitleOfCourtesy],
[t4].[BirthDate], [t4].[HireDate], [t4].[Address] AS [Address2],
[t4].[City] AS [City2], [t4].[Region] AS [Region2],
[t4].[PostalCode] AS [PostalCode2], [t4].[Country] AS [Country2],
[t4].[HomePhone], [t4].[Extension], [t4].[Notes], [t4].[ReportsTo],
[t6].[test] AS [test3], [t6].[ShipperID],
[t6].[CompanyName] AS [CompanyName2], [t6].[Phone] AS [Phone2]
FROM [dbo].[Orders] AS [t0]
LEFT OUTER JOIN (
SELECT 1 AS [test], [t1].[CustomerID], [t1].[CompanyName],
[t1].[ContactName], [t1].[ContactTitle], [t1].[Address],
[t1].[City], [t1].[Region], [t1].[PostalCode], [t1].[Country],
[t1].[Phone], [t1].[Fax]
FROM [dbo].[Customers] AS [t1]
) AS [t2] ON [t2].[CustomerID] = [t0].[CustomerID]
LEFT OUTER JOIN (
SELECT 1 AS [test], [t3].[EmployeeID], [t3].[LastName],
[t3].[FirstName], [t3].[Title], [t3].[TitleOfCourtesy],
[t3].[BirthDate], [t3].[HireDate], [t3].[Address], [t3].[City],
[t3].[Region], [t3].[PostalCode], [t3].[Country], [t3].[HomePhone],
[t3].[Extension], [t3].[Notes], [t3].[ReportsTo]
FROM [dbo].[Employees] AS [t3]
) AS [t4] ON [t4].[EmployeeID] = [t0].[EmployeeID]
LEFT OUTER JOIN (
SELECT 1 AS [test], [t5].[ShipperID], [t5].[CompanyName],
[t5].[Phone]
FROM [dbo].[Shippers] AS [t5]
) AS [t6] ON [t6].[ShipperID] = [t0].[ShipVia]
) AS [t7]
WHERE [t7].[ROW_NUMBER] > @p0',N'@p0 int',@p0=15
В общем, если шеф такое увидит, я не знаю, что со мной будет. Ясно одно — будет больно и недолго.
Здравствуйте, снежок, Вы писали:
С>Просто существуют data-ориентированные системы/решение и решения где тяжеловато обойтись без разветвленных бизнес-классов.
Хм. Либо data-ориентированное приложение, либо развесистые бизнес-классы. А так — да, LINQ2SQL предназначен для data driven решений.
VD>>Не спеши возмущаться. Твое сознание зашорено теми догмами которые впишивали в него индустриальные проповедники. Возможно когда-то ты прицдешь к выводу, что O/R-маперы шаг в не верном направлении.
T>Где же верное направление?
Уметь вернуться к структурам, т.е. к кортежам, когда речь идёт о данных. Классический объект — это сущность, которая прячет своё устройство, а данные наоборот — на виду. Где-то должен быть плавный и безболезненный переход из одной абстракции в другую.
Тут даже сложно еще что-либо добавить...
Я тоже не сторонник "авто-запросов", поэтому если и интересовался какими-либо ORM-ами и Mapping-Helper-ами, всегда в первую очередь смотрел на возможность пустить их CRUD-логику через использование хп, а на прямые обращения к таблицам и вьюхам вообще права отбираю всегда.
Но до сих пор более менее нормального не существовало и наверное не существует.
Я пытаюсь рассмотреть EDF не с точки зрения "авто-генератора запросов налету", а скорее как Bussiness Object Library + Mapping-Helper на storedProc (это тоже не совсем тривиальная задача), если это будет нормально получаться, то почему бы и нет?
Но я, так же как и ты, никогда не буду работать с сервером посредством вот такой вот тупой авто-генерации запросов, будь то EDF,LINQ или NHibernate или еще что-либо.
В случае необходимости разобраться с косяками, запускаешь профайлер и можно сразу идти за веревкой с мылом, потому как разобраться в таком бардаке...
Здравствуйте, tripolox, Вы писали:
VD>>Не спеши возмущаться. Твое сознание зашорено теми догмами которые впишивали в него индустриальные проповедники. Возможно когда-то ты прицдешь к выводу, что O/R-маперы шаг в не верном направлении.
T>Где же верное направление?
На мой взгляд O/R-маперы шаг в никуда. Данные == списки. LINQ to SQL средство повзволяющиее обрабатывать списки данных с приемлемым качеством и без существенных компромисов.
Большинство же O/R-маперов предполагают, что данные == отражение объектов на хранилище данных (persistent storage). Идея "постоянного хранения объектов", на мой взгляд является полной глупостью. Объектв — это представление данных в програме. Они не должны существовать виртуально. Мы создаем их чтобы облегчить свое восприятие данных.
Линк позволяет оперировать непосредсвенно кортежами. Достаточно создать простой слой абстракции между кортежами и представлением данных для клиента и все эти заморочки с O/R-маперами можно забыть как недоразумение.
На самом деле SQL и его эмуляция в LINQ намного мощьнее нежели стандартные методы предлагаемые императивным программированием (по существу тупые переборы). Достаточно сравнить:
foreach (cust in customers)
{
Orders ords = Lookup(orders, cust.id);
if (ords.Amount >= 100 && cust.Discount > 0)
WriteLine("Пользователь {0} имеет скидку {1} в заказе {1}",
cust.Name, ords.Amount, ords.id);
}
и
vr result = cust in customers, ords in orders
where ord.customer_id == cust.customer_id && ords.Amount >= 100 && cust.Discount > 0;
foreach (x in from result)
WriteLine("Пользователь {0} имеет скидку {1} в заказе {1}",
x.Name, x.Amount, x.id)
Второй вариант более декларативен. Его можно и исполнить более эффективно (передать SQL-серверу который оптимизирует его выполнение), и читать проще (мы точно не встретим импиративных изменений получаемой коллекции или побочных действий).
Конечно над O/R-маперами тоже можно наворотить движок запросов. Вот только зачем сначала превращать списки в сложные иерархии объектов, а затем обратно? Это ведь приведет к неоптимальности и подвигнет работать с данными тем самым тупым перебором (как в первом примере). А это убьемт декларативность и создаст сложнсоти (ведь в императивном коде могут быть любые невидимые зависимости).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, снежок, Вы писали:
С>Скорее тут не направление может оказаться неправильным, а применение. С>Просто существуют data-ориентированные системы/решение и решения где тяжеловато обойтись без разветвленных бизнес-классов. Вот, видимо, LINQ to SQL позиционируется как решение для data-ориентированных систем. И хотя EDF полностью покрывает по возможностям LINQ to SQL — это весьма далекие друг от друга продукты.
Мнея очень давно интересовал странный факт. Много кто пытался создать O/R-маперы, но ни у кого так и не удалось создать "идеальный O/R-мапер". Все что получалось проигрывало по скрости и удобству SQL-ю который был придуман IBM чуть ли не раньше чем появился термин ООП. В итоге я прише к парадоксальному виводу. ОО-языки програмиирования более низкоуровневы нежели SQL. SQL — это декларативный язык запросов к абстрактным данным. ООП же подразумевает императивную обработку данных, которая являеся черезчур низкоуровневой. ООП с одной стороны привносит абстрации вроде инкапсуляции, полиморфизма и наследования, но с другой ничего не предлагает в области конструирования и выполнения запросов к данным. А БД — это в первую очередь хранилища данных. Причем списков данных, если быть более точным. В итоге O/R-мапер преуспели в области упаковки данные в объекты, но ровным счетом ничего не смогли предложить в области получения и обработки данных. Лучшее что было в них изобретено — это текстовые запросы которые в итоге конвертируются в запросы к БД.
Дикая идея "пирсистентности" по которой объекты живут дольше своей реальной жизни привели к проблемам опережающего чтения (надо ли при считывании заказа читать данные покупателя по этому заказу?) и т.п.
Линк — это попытка по рдугому взглянуть на данные. Не объекто ориентированно (в то же время представляя данные в виде объектов по мере возможности).
Мы просто аппелируем к спискам данных. Причем не важно в каком виде. Мы просто строим запросы к ним и получаем списки данных. Мы просим дать нам информацию из заказа, покупателя и еще чего-то и получаем только то что нужно. Проблема опережающего чтения отпадает сама собой, так как мы сами указываем то что хотим получить. Так же пропадает проблема императивности. Мы вместо горы if-ов и for/foreach-ев получаем стройный запрос который формулируется в терминах всего 4-5 фукнциональных примитивов (from, wheere, order by, select и т.п.).
В общем, объекты в Линке не более чем средство описать данные для того чтобы удобнее оперировать ими во время исполнения, а не идея спрецировать объектную модель на БД. И это замечательно, так как SQL-СУБД более гибка в области обработки данных нежели тот ООП котрый навязывается массам "умными книжками".
Причем ООП никто не отменяет. Все его приемущества можно использовать на уровне приложения. А при зарпросе к данным ползоваться терминами и абстракциями БД.
С>p/s/ спасибо за участие
Не за что. Я выражаю свое мнение которое может быть не верным.
Просто я в последнее время немало времени посвятил так называемому фунциональному стилю программирования, где упор делается не на объекты в понимании ООП, а на списки более открытых структур данных, и понял, что в этом что-то есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Ну и мои 5 копеек. Сразу, чтоб не флеймить. Сам по себе LINQ — забавная идея. Но вот реализация...
S>Она дико сырая.
Идея старше тебя и очень продумана. Ты наврено даже не подозреваешь, что базис этой идеи нзывается "Лямбда исчисления Чёрча".
S> Безумно раздражает, что вместо того, чтобы работать с сиквелом, который я знаю и понимаю, я должен работать с какой-то финтифлюшкой, которая изображает из себя сиквел, как его видят разработчики финтифлюшки.
Проблема в том, что создатели "финтифлюшки" считают тебя и дугих C#-разработчиков быдлокодерами которым бессмысленно давать суровую мат.модель лежащую под их решением. Они считают, что большинство C#-разработчиков — это индусы (по призванию, а не по национальности), и они тупо не поймут мудренного обоснования. Меж тем основание у Линк-а очень серьезное. SQL — это только форма.
S> Плохо видят кстати. Меня задолбало пытаться написать LINQ-запрос так, чтоб он хотя бы примерно соответствовал тому, что должно быть и угадывать, как поведёт себя SelectMany в сочетании с GroupBy и GroupJoin (да, кстати, Left Join'a нет. Потомучта.).
Это проблема абстрагирования. Запрос в Линк — это абстракция которая преобразуется в SQL в случае LINQ to SQL. Понятно, что "не идеальные оптимизаторы" БД могут воспринять получающийся запрос не очень адекватно. Но над СУБД и их оптимизаторами будут работать, и рано или поздно даже самые не оптимальные запросы будут выполняться оптимально, и эта проблема уйдет сама собой. А пока что мы вльны химичит с вьюхами и другими косвенными структурами СУБД, чтобы заставить СУБД воспринимать "линкованные" запросы.
S> Задолбало разбираться, почему я должен править что-то в xml-х кишках этого чудо-монстра, чтобы наконец заработали хранимые процедуры, а потом материться и переписывать параметризованные функции на вьюхи, чтобды эта падла нормально загружала details'ы.
Большинство действительно новых решений не совершенно. Можешь потрахаться пару лет с O/R-маперами пока Линк не доведут до ума. Вот только по мне так это убитое время.
S>Ндя. Обещал же. 5 копеек про LINQ for SQL.
S>1. Отсутствие отсоединённого режима работы. S>Я до сих пор не могу понять, почему либо я использую SqlQuery<T> (или как его там...) и терплю непрекращаюшиеся обращения к серверу на каждый чих, S> либо пытаюсь использовать EaferLoad с копированием загруженных элементов типа .ToBindingList() и натыкаюсь на весёлые грабли... Потому что EagerLoad тоже через попу работает))) Самое большее, что с его помощью можно добиться — чтобы загружались дети при обращении к родителю. В результате, если у вас 15 родительских записей, вам потребуется обратиться к серверу всего 15 раз. Мило, да?)
Мило. Именно по этому лучше вобще не заморачиваться на идею O/R-мапинга, а делать реальные запросы к реальным данным.
S>2. Производительность. На эту тему даже рыдать не хочется. Я не могу понять, почему жалкие полтыщи master/details строк должны загружаться по три-пять секунд? Аналогичный штук с датаадаптером на порядок шустрее.
Ну, а 0.5-1 секунда — это нормально? А если клиентов 1000, то ждем 16 сек. на запрос (1 000 / 60)?
Не надо тянуть ненужные данные. Это ответ на все вопросы.
Проблема у вас в головах. Вы привыкли к ООП. А данные — это данные. Берите нужные вам 20 строк и не ентитите себе и окружающим мозги разными master/details-ами.
Нужны данные по заказу вместе с деталировкой? Ну, так напиши запрос соеденяющий заказ и его деталировку. Нужен список заказов? Так тяни только его. А уж детали по отдельным заказам вытянишь потом отдельным запросом.
S>3. Lazy load. Ну вот раздражает меня тот факт, что результатом любого запроса могут быть устаревшие данные (не забываем, что все сущности весьма весело кэшируются внутри контекста). Даже если мне надо будет показывать лишь часть данных, я предпочту постраничную выборку. Потому что буду уверен, что все данные согласованы. И не буду гадать, сколько времени назад и что загрузилось.
Разражают? На то есть уровни изоляции. Хотя разумнее не раздражаться, а расчитывать на это. Программы будут более мастабируемыми.
S>4. Невозможность сериализации данных. Точнее так. Сериализовать их можно. А вот восстановить и определить какие данные надо вставить в БД, а какие не изменялись — хрен те. Официальный совет: восстанавливайте оригинальные версии и вносите все изменения заново. Опупеть, да?
Ага. Если думашь шаблонами O/R-маперов. И нормально если думашь о списках данных как о... э... списках данных.
S>5. Убогий сгенеренный код. Если начальство увидит, что код в продакшне обращается к серверу вот так (это для одного (!) родителя):...
А на что оптимизатор у СУБД?
S>В общем, если шеф такое увидит, я не знаю, что со мной будет. Ясно одно — будет больно и недолго.
Если шев дурак, то будет больно. Если умный, то он поймет и осознает тот факт, что неоптимальность запросов соптимизирует умный сервер, а вот выигрышь в контроле типов и интелесенсе будет напрямую увеличивать качество и скорость разработки прикладного кода. В итоге дурка заставит писать код самостоятельно. Умные воспользуется приемуществами ЛИНК-а.
S>Удачи вам в освоении новых технологий)
Во. Во. И пока ее как следует не освоят не стоит выражать сильных негодований. Иначе потом стыдно удет. Ведь болшинство негодований вызвано не реальными недостатками, а банальными штампами мышления навязанными испоьзуемыми до этого технологиями.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Ну и мои 5 копеек. Сразу, чтоб не флеймить. Сам по себе LINQ — забавная идея. Но вот реализация...
S>Она дико сырая. Безумно раздражает, что вместо того, чтобы работать с сиквелом, который я знаю и понимаю, я должен работать с какой-то финтифлюшкой,
... которую ты не знаешь и не понимаешь.
В принципе, дальше можно и не читать. От непонимания сплошные недоразумения. Утихший было холивар SQL vs OOP похоже разгорается вновь.
Давно уже пора понять, что RDBMS и OOP это ортогональные вещи, которые не мешают а прекрасно дополняют друг друга.
Когда в руках из инструментов, один молоток, то все задачи становятся похожими на гвозди (с) не помню. Но стоит взять в руки отвертку, и приходит понимание того, что кроме гвоздей существуют шурупы. И шурупы по сравнению с гвоздями имеют просто уникальные, казавшиеся раньше невозможными, свойства. Например, их легко можно выкрутить (если конечно, они не были забиты молотком ).
Увидел дизайнер в новой студии, ух ты — таблички мапятся на классы, значит новый ORM. А как сюда свои родные хранимки прикрутить? Не прикручиваются? Полный отстой! Гвозди забивать не удобно, а так похоже на молоток...
LINQ это интегрированый в язык механизм запросов для работы с наборами данных. А LINQ2SQL это всго лишь один из интерфейсов для этого механизма (наряду с LINQ2Entity, LINQ2XML, LINQ over dataset etc.)
LINQ вовсе не "изображает из себя сиквел", семантика похожая, но больше ничего общего. По идеалогии LINQ гораздо ближе к XSLT чем к SQL.
S>В общем жопа всё это. Впрочем, не меньшая, чем EF. Последнее вообще, по-моему, бред полный, ибо трактуется как средство для выноса концептуальной модели на сторону клиента.
Это где же ты такого наслушался? EF предлагает отделить концептуальную модель данных от физической. И для этого у него есть довольно развитый механизм маппинга. Это, кстати, помогает решить проблему, о которой ты говоришь далее: S>А теперь учтите, что у нас не одно приложение базу юзает. И каждое должно видеть эту базу по-своему, и не лезть куда не положено... У каждого приложения должна быть своя концептуальная модель, да?)))
Твоя база — это физическая модель, а каждое приложение как раз может иметь свою концептуальную модель, которые мапятся на одну физическую. S>В общем от лукавого всё это...
В общем, поменьше надо сосредотачиваться на том, что, куда и как проинсталирует тебе начальник, а побольше на сути изучаемых технологий.
Тогда бы стало очевидно, что за отложенной загрузкой, отсоединенным режимом работы с данными, сериализацией и прочими вещами надо идти в Entity Framework а не кувыркаться с Linq2Sql. Выгружать тысячи записей master/details было модно и нужно в давние времена клиент серверных архитектур (которые по этим причинам и почили в бозе), а для масштабируемых приложений так делать не принято. и т.д и т.п.
S>5. Убогий сгенеренный код. Если начальство увидит, что код в продакшне обращается к серверу вот так (это для одного (!) родителя):
А чем конкретно код не понравился?
Недавно, кстати прочитал где то в блогах что в команду EF специально откомандировали лучших спецов по оптимизации запросов из SQL Server core team.
Немножко отвлекаемся от общей темы дискуссии, но хочется еще немножко побеседовать про наследование.
С>Стоимость соединения я прикидываю на реальных данных в ходе внедрения или эксплуатации. С>И если оно, соединение, становится слишком дорогим, то я легко рефакторю "тяжелые" таблицы ко второму варианту реализации наследования, когда атрибуты предка дублируются в атрибутах потомка.
Оно конечно, вариант. Но когда вам потребуется выборка экземпляра некоторого базового типа — придется воротить несколько UNION'ов...
Ограничения, заданные на уровне СУБД для унаследованных колонок — также придется дублировать и синхронизировать. Дубляж данных, дубляж индексов...
Внешние ключи из других таблиц на таблицу базового типа... ну тут наверное нормально, но только если сохраняется связь один-к-одному.
Я это к тому, что такая схема тоже далеко не идеальна, далека от нормальной, и поиск компромисса вполне может закончиться в конкретном случае признанием модели SingleTableInheritance наиболее подходящей
С>На первоначальном этапе анализа и проектирования я никогда не заменяю наследование на атрибут-признак типа, так как с большой вероятностью на этом этапе может что то ускользнуть от твоего взгляда и при этом легко допустить ошибку проектирования. С>Я всегда смогу вернуться к рефакторингу в направлении создания атрибута-признака типа на завершающих этапах, если это решение действительно окажется удовлетворительным. Яркий пример когда введение атрибута-признака типа очень часто является ошибкой — это "Физические лица и Юридические лица".
На этапе анализа и проектирования концептуальной модели нет и не может быть никаких признаков типа. Мы говорим про ситуацию, когда такой признак — это не часть модели, а просто способ отличать типы объектов при хранении. Это отражает всего-лишь способ хранения, скрытый от прикладного кода.
Вас же пугает, что у любого объекта в памяти есть некий признак типа TypeHandle?
С>А рассуждая так, что в потомках отличающихся свойств раз два и обчелся, недолго дойти и до решения когда всю базу можно уложить в одну таблицу. Хотя я конечно же уверен что к такому маразму ты никогда не стремился
К хранению иерархии в одной таблице я тоже никогда не стремился. Было бы странно к этому стремиться.
А вот использовать как один из самых простых и эффективных способов хранения — приходилось, равно как и другие.
С>Я тоже не сторонник "авто-запросов", поэтому если и интересовался какими-либо ORM-ами и Mapping-Helper-ами, всегда в первую очередь смотрел на возможность пустить их CRUD-логику через использование хп, а на прямые обращения к таблицам и вьюхам вообще права отбираю всегда.
Обратите внимание, что CRUD — это совсем даже не Select
Подход с процедурами может быть хорош, если у вас малое число различных запросов в системе.
А если большое число разных запросов? Ну вот задача такая!
Именно эту задачу и пытается помочь решить LINQ в большинстве случаев.
Совершенно очевидно, что ВСЕГДА (это значит ВСЕГДА) будет некоторый процент таких запросов, которые надо писать и пускать руками, в которых вылизан каждый хинт и который не напишет ни один генератор и не соптимизирует ни один железный оптимизатор. Ну так и пускайте его руками! Но процент таких запросов обычно очень невелик! Если у вас не так, можно только посочуствовать (или поздравить — у вас нестандартные проекты!).
А LINQ (и иже с ним) можно пробовать использовать в той огромной массе кода, где корректность гораздо важнее оптимальности (по крайней мере на начальном этапе).
LINQ за счет удобства использования и статического контроля снижает вероятность ошибок, повышает читаемость и именно в этом его плюс.
Не надо искать в нем лекарство от всех болезней!
С>Но я, так же как и ты, никогда не буду работать с сервером посредством вот такой вот тупой авто-генерации запросов, будь то EDF,LINQ или NHibernate или еще что-либо.
Дело, конечно, ваше. В любом случае, странно, если вам не нравятся запросы NHibernate, то чего вы такого волшебного ждали от LINQ?
А я вот например, с удовольствием поиспользую LINQ в своих проектах.
Конечно, не со стандартным LINQ-to-SQL, а со своим back-end'ом
Куда я напишу такую генерацию SQL, которая мне нужна.
И который сможет делать выборки в памяти по возможности.
И что еще там мне потребуется.
Тут же все как обычно — M$ сделал фичу в языке и парочку референсных штук, использующих эту фичу.
И часто лучшей практикой оказывается выкинуть этот референс и используя фичу, сделать все так, как тебе надо
S>А чем конкретно код не понравился? S>Недавно, кстати прочитал где то в блогах что в команду EF специально откомандировали лучших спецов по оптимизации запросов из SQL Server core team.
То то весь код кишит LEFT OUTER JOIN — ами.
Т.е. почти везде подразумеваем справа NULL-ы по ключам при соединении, да?
А всегда ли это справедливо в этих запросах? Или может маппинг где недокрутили? Теперь закрученные отверткой шурупчики будем под микроскопом пинцетиком поправлять?
Хотя конечно по логике LINQ-запроса нужно смотреть, но вот только непонятно сразу откуда это идет из кода, стояло бы exec GetOrderDetail @p1, @p2 ... совсем другое дело.
Меня на самом деле вот что настораживает — как бы каждый "индус по призванию" не начал LINQ-запросы лепить везде где не попади в целях сверхбыстрого создания кода "сверхнового поколения". И как бы не получить откат к размазыванию запросов (пусть linq-запросов) по слоям. Ведь "удобно" же становится... навесил сразу же на OnClick linq-запрос и готово, зачем нам знать всякие MVC, Front- и ApplicationConntoller, DynamicProxy и прочую лабудень из паттернов?
И сервисы свои в сторону, Astoria всех спасет
Только потом куча этих индусских проектов качует бравым парням из Дубны... Но ничего, они могучие, все отрефакторят как надо.
Не смешно?
iT>Оно конечно, вариант. Но когда вам потребуется выборка экземпляра некоторого базового типа — придется воротить несколько UNION'ов...
Да, так оно и есть, рефакторится лишь соответствующая базовая view и select f from BaseTable заменяется
select f from BaseTable
union all
select f from Child1
union all
select f from Child2
iT>Ограничения, заданные на уровне СУБД для унаследованных колонок — также придется дублировать и синхронизировать. Придется, но такова природа данного типа наследования.
Дублировать и синхронизировать индексы и ограничения приходится и при разнесении тяжелых таблиц по partition-ам (partitioned view), ну и что, теперь из-за этого не использовать partitioned view/table?
iT>Я это к тому, что такая схема тоже далеко не идеальна, далека от нормальной, и поиск компромисса вполне может закончиться в конкретном случае признанием модели SingleTableInheritance наиболее подходящей
Модель SingleTableInheritance ведет только к одному — к появлению NULL-ов и денормализации, которая впринципе подходящий вариант в OLAP, но ни как не в оперативной БД.
Хотя лишний раз и не хочется поднимать флеймогонных тем, но всегда когда есть искушение заюзать NULL-ы я отношусь к этому как к потенциальной ошибке проектирования, хоть компромисы и возможны.
Обычно искусственно ставлю себе в этом случае планку — одно-два поля, не более, иначе — выделять в нормальных потомков. И то, такое решение (SingleTableInheritance) принимается на заключительных стадиях/витках проектирования.
iT>На этапе анализа и проектирования концептуальной модели нет и не может быть никаких признаков типа. Мы говорим про ситуацию, когда такой признак — это не часть модели, а просто способ отличать типы объектов при хранении. Это отражает всего-лишь способ хранения, скрытый от прикладного кода. iT>Вас же пугает, что у любого объекта в памяти есть некий признак типа TypeHandle?
Нет, как раз признак типа меня не пугает, он как раз таки обычно присутствует во всех типах наследования, хотябы как информационное поле. Меня пугает то, что творится внутри этой таблицы, и кстати, невозможность на уровне таблицы построить constaraint по полю потомка, который должен быть применим только для одного типа. Т.е. в случае SingleTableInheritance применяем constraint либо ко всем типам, либо вообще его не создаем и контролируем его в другом месте.
iT>К хранению иерархии в одной таблице я тоже никогда не стремился. Было бы странно к этому стремиться. iT>А вот использовать как один из самых простых и эффективных способов хранения — приходилось, равно как и другие.
В любом подходе должна быть мера и здравый смысл, не так ли?
Эть... вот за что я люблю РСДН) Стоит от души пожаловаться на жизнь, и тут же тебя все поддержат)
Вежливо отпишемся по пунктам. Если начну срываться в холивар — пинайте)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinix, Вы писали:
S>>Ну и мои 5 копеек. Сразу, чтоб не флеймить. Сам по себе LINQ — забавная идея. Но вот реализация...
S>>Она дико сырая.
VD>Идея старше тебя и очень продумана. Ты наврено даже не подозреваешь, что базис этой идеи нзывается "Лямбда исчисления Чёрча".
Идея — да, да и ещё раз да. Я не собираюсь про это спорить. Я про конкретную реализацию. Я наверно даже не подозреваю, что тот кто её делал, слышал про "Лямбда исчисления Чёрча") Тут уже была куча холиваров... есть лямбды в 3-м шарпе, не есть лямбды... сколько можно?)
S>> Безумно раздражает, что вместо того, чтобы работать с сиквелом, который я знаю и понимаю, я должен работать с какой-то финтифлюшкой, которая изображает из себя сиквел, как его видят разработчики финтифлюшки.
VD>Проблема в том, что создатели "финтифлюшки" считают тебя и дугих C#-разработчиков быдлокодерами которым бессмысленно давать суровую мат.модель лежащую под их решением. Они считают, что большинство C#-разработчиков — это индусы (по призванию, а не по национальности), и они тупо не поймут мудренного обоснования. Меж тем основание у Линк-а очень серьезное. SQL — это только форма.
Про обоснование согласен. Про быдлокодеров — отдельный холивар.
S>> Плохо видят кстати. Меня задолбало пытаться написать LINQ-запрос так, чтоб он хотя бы примерно соответствовал тому, что должно быть и угадывать, как поведёт себя SelectMany в сочетании с GroupBy и GroupJoin (да, кстати, Left Join'a нет. Потомучта.).
VD>Это проблема абстрагирования. Запрос в Линк — это абстракция которая преобразуется в SQL в случае LINQ to SQL. Понятно, что "не идеальные оптимизаторы" БД могут воспринять получающийся запрос не очень адекватно. Но над СУБД и их оптимизаторами будут работать, и рано или поздно даже самые не оптимальные запросы будут выполняться оптимально, и эта проблема уйдет сама собой. А пока что мы вльны химичит с вьюхами и другими косвенными структурами СУБД, чтобы заставить СУБД воспринимать "линкованные" запросы.
Тоже согласен. Но вот насчёт будущей доработанности LINQ for SQL сиильна сомневаюсь. Чтобы не быть голословным. Есть такой дяденька, Frans Bouma. Один из команды разработчиков платного ормаппера LLBLGen Pro. И вот в его блоге есть чудная-чудная история в девяти частях про прикручивания LINQ к их мапперу. Очень советую осилить, перед тем, как холиварить на тему LINQ.
S>> Задолбало разбираться, почему я должен править что-то в xml-х кишках этого чудо-монстра, чтобы наконец заработали хранимые процедуры, а потом материться и переписывать параметризованные функции на вьюхи, чтобды эта падла нормально загружала details'ы.
VD>Большинство действительно новых решений не совершенно. Можешь потрахаться пару лет с O/R-маперами пока Линк не доведут до ума. Вот только по мне так это убитое время.
И о чём мы спорим?)
S>>Ндя. Обещал же. 5 копеек про LINQ for SQL.
S>>1. Отсутствие отсоединённого режима работы. S>>Я до сих пор не могу понять, почему либо я использую SqlQuery<T> (или как его там...) и терплю непрекращаюшиеся обращения к серверу на каждый чих, S>> либо пытаюсь использовать EaferLoad с копированием загруженных элементов типа .ToBindingList() и натыкаюсь на весёлые грабли... Потому что EagerLoad тоже через попу работает))) Самое большее, что с его помощью можно добиться — чтобы загружались дети при обращении к родителю. В результате, если у вас 15 родительских записей, вам потребуется обратиться к серверу всего 15 раз. Мило, да?)
VD>Мило. Именно по этому лучше вобще не заморачиваться на идею O/R-мапинга, а делать реальные запросы к реальным данным.
Угу.
S>>2. Производительность. На эту тему даже рыдать не хочется. Я не могу понять, почему жалкие полтыщи master/details строк должны загружаться по три-пять секунд? Аналогичный штук с датаадаптером на порядок шустрее.
VD>Ну, а 0.5-1 секунда — это нормально? А если клиентов 1000, то ждем 16 сек. на запрос (1 000 / 60)? VD>Не надо тянуть ненужные данные. Это ответ на все вопросы. VD>Проблема у вас в головах. Вы привыкли к ООП. А данные — это данные. Берите нужные вам 20 строк и не ентитите себе и окружающим мозги разными master/details-ами. VD>Нужны данные по заказу вместе с деталировкой? Ну, так напиши запрос соеденяющий заказ и его деталировку. Нужен список заказов? Так тяни только его. А уж детали по отдельным заказам вытянишь потом отдельным запросом.
Ээть. Ну как сказать. У нас тестовый сервер тогда крутился на Cel 1.8/512 (не помню уже, зачем так извращались). И там ещё мноого чего запущено. В общем для тех условий и полсекунды — нереально много. Потому как там не тупой select from where был.
Почему я привык к ООП? я как не странно не стараюсь написать свой "бизнес-объект" на каждый чих. До сих пор по старинке датасетами пользуемся)
Ну и насчёт нужных мне 20 строк. Если бы всё так просто было... Вы считаете что утянуть полтыщи строк за один раз и изредка их рефрешить куда медленнее, чем пихать при каждом скроле сервер тем же самым запросом, да ещё и с сортировкой (пусть и ограниченной с помощью top)?
И что вы все так сразу к мастер-детайлсам цепляетесь?) Если я скажу, что там не совсем мастер-детайлсы, это вас успокоит?)
S>>3. Lazy load. Ну вот раздражает меня тот факт, что результатом любого запроса могут быть устаревшие данные (не забываем, что все сущности весьма весело кэшируются внутри контекста). Даже если мне надо будет показывать лишь часть данных, я предпочту постраничную выборку. Потому что буду уверен, что все данные согласованы. И не буду гадать, сколько времени назад и что загрузилось.
VD>Разражают? На то есть уровни изоляции. Хотя разумнее не раздражаться, а расчитывать на это. Программы будут более мастабируемыми.
Таак. То есть, то, что клиент одновременно видит и устаревшие, и свежие данные — это уже преимущество?) Ну и про уровни изоляции. Вы надеюсь не предлагаете держать serialized транзакцию, пока пользователь не проскролит по списку?)
S>>4. Невозможность сериализации данных. Точнее так. Сериализовать их можно. А вот восстановить и определить какие данные надо вставить в БД, а какие не изменялись — хрен те. Официальный совет: восстанавливайте оригинальные версии и вносите все изменения заново. Опупеть, да?
VD>Ага. Если думашь шаблонами O/R-маперов. И нормально если думашь о списках данных как о... э... списках данных.
Угк. В общем я даже комментировать не хочу особо. Никогда не требовалось организовать удалённую обработку данных с последующим внесением изменений?) Так вот. LINQ for SQL в своём текущем состоянии этого не позволяет.
S>>5. Убогий сгенеренный код. Если начальство увидит, что код в продакшне обращается к серверу вот так (это для одного (!) родителя):...
VD>А на что оптимизатор у СУБД?
S>>В общем, если шеф такое увидит, я не знаю, что со мной будет. Ясно одно — будет больно и недолго.
VD>Если шев дурак, то будет больно. Если умный, то он поймет и осознает тот факт, что неоптимальность запросов соптимизирует умный сервер, а вот выигрышь в контроле типов и интелесенсе будет напрямую увеличивать качество и скорость разработки прикладного кода. В итоге дурка заставит писать код самостоятельно. Умные воспользуется приемуществами ЛИНК-а.
Гм. Шеф как раз не дурак. И он понимает, что ни один оптимайзер не способен вас защитить от идиота, который пихает left join'ы и сортировку где надо и не надо. А контроль типов и интеллисенс худо-бедно обеспечивают те же типизированные датасеты.
S>>Удачи вам в освоении новых технологий)
VD>Во. Во. И пока ее как следует не освоят не стоит выражать сильных негодований. Иначе потом стыдно удет. Ведь болшинство негодований вызвано не реальными недостатками, а банальными штампами мышления навязанными испоьзуемыми до этого технологиями.
А я не негодую. Я делюсь наболевшим. Приятного холивара)
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Sinix, Вы писали:
S>>Ну и мои 5 копеек. Сразу, чтоб не флеймить. Сам по себе LINQ — забавная идея. Но вот реализация... S>>Она дико сырая. Безумно раздражает, что вместо того, чтобы работать с сиквелом, который я знаю и понимаю, я должен работать с какой-то финтифлюшкой,
S>... которую ты не знаешь и не понимаешь.
Гм, а хамить обязательно?)
S>Увидел дизайнер в новой студии, ух ты — таблички мапятся на классы, значит новый ORM. А как сюда свои родные хранимки прикрутить? Не прикручиваются? Полный отстой! Гвозди забивать не удобно, а так похоже на молоток...
Гм. Ну как ни странно, мне казалось, что если "таблички мапятся на классы" — то эту уже нечто с претензией на ормапистость. И если что, с дизайнером как-то не игрались, всё честно — классы плюс attribute-mapping.
S>LINQ это интегрированый в язык механизм запросов для работы с наборами данных. А LINQ2SQL это всго лишь один из интерфейсов для этого механизма (наряду с LINQ2Entity, LINQ2XML, LINQ over dataset etc.) S>LINQ вовсе не "изображает из себя сиквел", семантика похожая, но больше ничего общего. По идеалогии LINQ гораздо ближе к XSLT чем к SQL.
Угу.
S>>В общем жопа всё это. Впрочем, не меньшая, чем EF. Последнее вообще, по-моему, бред полный, ибо трактуется как средство для выноса концептуальной модели на сторону клиента.
S>Это где же ты такого наслушался? EF предлагает отделить концептуальную модель данных от физической. И для этого у него есть довольно развитый механизм маппинга. Это, кстати, помогает решить проблему, о которой ты говоришь далее: S>>А теперь учтите, что у нас не одно приложение базу юзает. И каждое должно видеть эту базу по-своему, и не лезть куда не положено... У каждого приложения должна быть своя концептуальная модель, да?)))
The above LINQ query looks a lot like something you would write in T-SQL (odd syntax notwithstanding), but actually, you are writing to the conceptual model. What does this mean? This means that you now have more control over the database!
S>Твоя база — это физическая модель, а каждое приложение как раз может иметь свою концептуальную модель, которые мапятся на одну физическую.
ГГГ. Читайте умных людей. Дейта для начала. Или стандарты. Например, древняя-древняя архитектура ИС, придложенная ANSI/SPARC в восемдесят лохматом году.
Упошлённо:
Есть 3 уровня: физическая реализация, концептуальная модель и пользовательские представления.
Есть маппинги между этими уровнями.
Любое пользовательское представление основывается на маппинге к концептуальной модели и (или) на маппинге к другим пользовательским представлениям.
Любой клиент обращается к системе только через пользовательское представление.
Не находите, что это чуть-чуть отличается от вашей трактовки?)
S>>В общем от лукавого всё это... S>В общем, поменьше надо сосредотачиваться на том, что, куда и как проинсталирует тебе начальник, а побольше на сути изучаемых технологий. S>Тогда бы стало очевидно, что за отложенной загрузкой, отсоединенным режимом работы с данными, сериализацией и прочими вещами надо идти в Entity Framework а не кувыркаться с Linq2Sql.
Гм. А зачем тогда оно там есть? Для Галочки?)
S> Выгружать тысячи записей master/details было модно и нужно в давние времена клиент серверных архитектур (которые по этим причинам и почили в бозе), а для масштабируемых приложений так делать не принято. и т.д и т.п.
Ы) мы почили в бозе, мы почили в бозе, мы почили в бозе...
Вы с файл-серверными приложениями не путаете часом? Хотя и они ещё живы. Та же 1С...
S>>5. Убогий сгенеренный код. Если начальство увидит, что код в продакшне обращается к серверу вот так (это для одного (!) родителя):
S>А чем конкретно код не понравился?
Не настораживает сортировка по всем полям и захардкоденная последовательность соединений из-за лефтжойнов???
S>Недавно, кстати прочитал где то в блогах что в команду EF специально откомандировали лучших спецов по оптимизации запросов из SQL Server core team.
Здравствуйте, Sinix, Вы писали:
S>>>Она дико сырая. Безумно раздражает, что вместо того, чтобы работать с сиквелом, который я знаю и понимаю, я должен работать с какой-то финтифлюшкой,
S>>... которую ты не знаешь и не понимаешь.
S>Гм, а хамить обязательно?)
Хамить? На "ты" обиделся, или на то что я упрекаю тебя в недостаточном знании предмета? Хорошо, перейду на вы.
Я (и не только я один) просто констатирую факт того, что вы не достаточно разобравшись с предметом пытаетесь использовать его не по назначению и при этом делаете категорические выводы.
Вы пытаетесь молотком забивать шурупы и при этом отчаянно ругаетесь на то, что они не похожи на гвозди.
S>Например, такая весёлая агитационная дока "Админам СУБД про entity framework" где английским по белому идёт следующее:
S>The above LINQ query looks a lot like something you would write in T-SQL (odd syntax notwithstanding), but actually, you are writing to the conceptual model. What does this mean? This means that you now have more control over the database!
Я читал это. Редкостный бред...
S>>Твоя база — это физическая модель, а каждое приложение как раз может иметь свою концептуальную модель, которые мапятся на одну физическую.
S>ГГГ. Читайте умных людей. Дейта для начала. Или стандарты. Например, древняя-древняя архитектура ИС, придложенная ANSI/SPARC в восемдесят лохматом году. S>Упошлённо: S>Есть 3 уровня: физическая реализация, концептуальная модель и пользовательские представления. S>Есть маппинги между этими уровнями. S>Любое пользовательское представление основывается на маппинге к концептуальной модели и (или) на маппинге к другим пользовательским представлениям. S>Любой клиент обращается к системе только через пользовательское представление.
S>Не находите, что это чуть-чуть отличается от вашей трактовки?)
Ну, так это не моя трактовка, а тех кто делает EF. Можете их урекать, что они в детстве мало Дейта читали
Эти ребята оперируют треминами "The Conceptual Model" и "The Storage Model". Чего флеймить? Откройте help по EF и почитайте. Они разрабатывают фрэймворк кторым мы пользуемся, и поэтому они диктуют терминологию а не мы. Вы создайте собственный движок и можете оределять там термины, как вам нравится.
S>>Тогда бы стало очевидно, что за отложенной загрузкой, отсоединенным режимом работы с данными, сериализацией и прочими вещами надо идти в Entity Framework а не кувыркаться с Linq2Sql.
S>Гм. А зачем тогда оно там есть? Для Галочки?)
В точку, только пожалуй "галочка" — с маленькой буквы . Но, я заюзал бы System.Data.Linq вместо System.Data.Entity в каком нибудь небольшом web приложении или интерактивном прототипе. Очень удобные там вещи есть, вроде выведения типов и строгой типизации в запросах.
S>> Выгружать тысячи записей master/details было модно и нужно в давние времена клиент серверных архитектур (которые по этим причинам и почили в бозе), а для масштабируемых приложений так делать не принято. и т.д и т.п.
S>Ы) мы почили в бозе, мы почили в бозе, мы почили в бозе... S>Вы с файл-серверными приложениями не путаете часом? Хотя и они ещё живы. Та же 1С...
Живы конечно. У бизнес приложений долгая жизнь. Я говорил об архитектуре а не оприложениях. Разницу улавливаете?
S>>>5. Убогий сгенеренный код. Если начальство увидит, что код в продакшне обращается к серверу вот так (это для одного (!) родителя):
S>>А чем конкретно код не понравился?
S>Не настораживает сортировка по всем полям и захардкоденная последовательность соединений из-за лефтжойнов???
Нет, не настораживает, это же кодогенератор.
Возможно я не стал бы использовать эту штуку в высоконагруженной системе, и то только после соответствующих нагрузочных тестов. Не имею привычки заниматься преждевременной оптимизацией.
S>>Недавно, кстати прочитал где то в блогах что в команду EF специально откомандировали лучших спецов по оптимизации запросов из SQL Server core team.
S>Ссылку.
Найду, скину.
S>Удачи. И не хамите, пожалуйста. Читать неприятно)
Ваши пассажи тоже читать не очень приятно. В исходном сообщении вы в достаточно хамской форме упрекаете разработчиков LINQ в непонимании SQL, а когда в непонимании LINQ упрекают вас, то вы вспоминаете об этикете. Ведите себя соответственно и не будет поводов для обид.
S>Тоже согласен. Но вот насчёт будущей доработанности LINQ for SQL сиильна сомневаюсь. Чтобы не быть голословным. Есть такой дяденька, Frans Bouma. Один из команды разработчиков платного ормаппера LLBLGen Pro. И вот в его блоге есть чудная-чудная история в девяти частях про прикручивания LINQ к их мапперу. Очень советую осилить, перед тем, как холиварить на тему LINQ.
Я вот начал читать, и как-то мне кажется, что чувак там в основном мимо тазика мечет. Нет, он тоже MVP, все дела, но первый же SQL, который он приводит для обоснования убогости Linq, заставляет меня сомневаться в очевидном:
-- TSQL, using '*' for simplicitySELECT E.* FROM Employees E LEFT JOIN Orders O
ON E.EmployeeID = O.EmployeeID
WHERE O.OrderID IS NULL
Это для решения задачи "построить список сотрудников, у которых нет заказов".
Ну кто так пишет? Индусы? Надо полагать, для построения сотрудников, у которых есть заказы, пацан напишет что-то вроде
-- TSQL, using '*' for simplicitySELECT E.* FROM Employees E LEFT JOIN Orders O
ON E.EmployeeID = O.EmployeeID
WHERE O.OrderID IS not null
Потом он, ясен пень, исправит это на
SELECTdistinct E.* FROM Employees E LEFT JOIN Orders O
ON E.EmployeeID = O.EmployeeID
WHERE O.OrderID IS not null
И всё это в надежде на то, что сервер сам соптимизирует этот быдлокод.
Лично мне при словах "построить список сотрудников, у которых нет заказов" left join в голову не приходит. А приходит что-то вроде
-- TSQL, using '*' for simplicitySELECT E.* FROM Employees E
where not exists (select OrderId from orders o where E.EmployeeID = O.EmployeeID)
Это несколько точнее отражает намерения разработчика, вы не находите?
Излишне говорить, что этот подход находит мгновенное отражение в Linq to SQL:
var q = from e in ds.Employees
where ! e.Orders.Any()
select e;
Ну и где все эти ужоснахи, про которые рассказывает нам дяденька Bouma?
Может, сгенерируется монструозный SQL? Вот он:
SELECT [t0].[Id], [t0].[Name]
FROM [dbo].[Employees] AS [t0]
WHERE NOT (EXISTS(
SELECT NULL AS [EMPTY]
FROM [dbo].[Orders] AS [t1]
WHERE [t1].[EmployeeID] = [t0].[Id]
))
Какие проблемы-то?
Про его рассуждения типа "как нам загрузить граф объектов, да не простой, а с подвыподвертом" — это всё мимо кассы. Все рассказы про то, что "это я мог и в своем O/R маппере" тоже, похоже, от избытка интеллекта. Ну вот мы у себя гоняем O/R маппер, Genome называется. Нормальный чисто текстовый OQL, с полным отсутствием компайл-тайм проверки; с кучей ограничений на предикаты и прочее. С нетерпением ждем возможности перейти на линк и выкинуть это как страшный сон.
S>Гм. Шеф как раз не дурак. И он понимает, что ни один оптимайзер не способен вас защитить от идиота, который пихает left join'ы и сортировку где надо и не надо. А контроль типов и интеллисенс худо-бедно обеспечивают те же типизированные датасеты.
Ну так не будьте идиотами, не пихате left join куда не надо.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Ну так не будьте идиотами, не пихате left join куда не надо.
Дык как раз мало таких идиотов, дело в том что пихает их генератор, а пихает их потому, что девелопер сделал неоптимальный LINQ-запрос (или не естественно выглядящий для генератора), в то же время девелопер не дурак, и он на T-SQL конечно же использовал бы exists.
Сейчас же выходит, что девелопер должен хорошо знать и писать и LINQ-запросы, и запросы на T-SQL, и не только знать, но и хорошо сопоставлять их, предугадывая что LINQ там может нагенерить.
Здравствуйте, Sinix, Вы писали:
S>Тоже согласен. Но вот насчёт будущей доработанности LINQ for SQL сиильна сомневаюсь. Чтобы не быть голословным. Есть такой дяденька, Frans Bouma. Один из команды разработчиков платного ормаппера LLBLGen Pro.
У Франса — рыльце в пушку. Он отчаянно пиарит свой LLBLGen и пытается его пропихнуть везде, где можно, задрал уже, честно говоря.
И все сценарии, на которых пытается доказать, что линк сливает его творению, как-то не кажутся мне жизненными (для тех целей, для которых linq2sql создавался), сколько я на них не смотрю. LINQ2SQL конечно тоже не идеал, все таки первая версия, но вот фатальных косяков мне пока не встречалось, пока все довольно логично и вполне вписывается в мои сценарии.
S>Почему я привык к ООП? я как не странно не стараюсь написать свой "бизнес-объект" на каждый чих. До сих пор по старинке датасетами пользуемся)
Ну и сами виноваты..
S>Угк. В общем я даже комментировать не хочу особо. Никогда не требовалось организовать удалённую обработку данных с последующим внесением изменений?) Так вот. LINQ for SQL в своём текущем состоянии этого не позволяет.
Позволяет. Правда, в несколько ограниченном виде, но вполне позволяет, причем этого ограниченного вполне хватает для большинства сценариев. В следующей версии, доведут до ума окончательно, к сожалению к этому релизу не успели...
S>А контроль типов и интеллисенс худо-бедно обеспечивают те же типизированные датасеты.
Настолько худо и бедно, что лучше с ними вообще не связываться. =)
Здравствуйте, снежок, Вы писали:
С>Дык как раз мало таких идиотов, дело в том что пихает их генератор, а пихает их потому, что девелопер сделал неоптимальный LINQ-запрос (или не естественно выглядящий для генератора), в то же время девелопер не дурак, и он на T-SQL конечно же использовал бы exists.
Ну нет не использовал бы. Почитай статью — чувак начинает с left join (который вообще говоря малознакомому с SQL человеку покажется полным бредом — что это за where Id is null, когда у меня на эту колонку is not null констреинт стоит), а потом начинает обвинять линку. С>Сейчас же выходит, что девелопер должен хорошо знать и писать и LINQ-запросы, и запросы на T-SQL, и не только знать, но и хорошо сопоставлять их, предугадывая что LINQ там может нагенерить.
Ничего предугадывать не надо. Достаточно поставить брекпоинт и навести мышой на запрос, чтобы тебе сразу показали получившийся T-SQL. Запросы на Linq, как и на SQL, нужно писать декларативно. То есть максимально стремиться к тому, чтобы описывать, что хочется получить. А не побочные эффекты, типа "загрузить еще и детей, хотя я на них не ссылаюсь".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: LINQ to SQL. первые разочарования.
От:
Аноним
Дата:
12.12.07 10:23
Оценка:
Здравствуйте, IB, Вы писали:
S>>Угк. В общем я даже комментировать не хочу особо. Никогда не требовалось организовать удалённую обработку данных с последующим внесением изменений?) Так вот. LINQ for SQL в своём текущем состоянии этого не позволяет. IB>Позволяет. Правда, в несколько ограниченном виде, но вполне позволяет, причем этого ограниченного вполне хватает для большинства сценариев. В следующей версии, доведут до ума окончательно, к сожалению к этому релизу не успели...
а, если не секрет, каким образом позволяет?
Мы даже на платформе2008 у "эксперта" спрашивали и про EF и про LINQ, нам ответили, типа не парьтесь и используйте прокси. После этого я попытался рассказать, что прокси — это не то, но нам снова ответили "не парьтесь и используйте прокси". Больше спрашивать не хотелось.
S>Тоже согласен. Но вот насчёт будущей доработанности LINQ for SQL сиильна сомневаюсь. Чтобы не быть голословным. Есть такой дяденька, Frans Bouma. Один из команды разработчиков платного ормаппера LLBLGen Pro. И вот в его блоге есть чудная-чудная история в девяти частях про прикручивания LINQ к их мапперу. Очень советую осилить, перед тем, как холиварить на тему LINQ.
Было бы странно, если бы Frans Bouma не ругал LINQ. Он ведь напрямую отнимает у него хлеб . Он кстати не только LINQ ругает, но и другие ORM (Nhibernate например).
S>Гм. Шеф как раз не дурак. И он понимает, что ни один оптимайзер не способен вас защитить от идиота, который пихает left join'ы и сортировку где надо и не надо. А контроль типов и интеллисенс худо-бедно обеспечивают те же типизированные датасеты.
Просветите, каким образом датасет может обеспечить типизацию или интеллисенс при написании запроса (а не при чтении результатов).
IB>У Франса — рыльце в пушку. Он отчаянно пиарит свой LLBLGen и пытается его пропихнуть везде, где можно, задрал уже, честно говоря. IB>И все сценарии, на которых пытается доказать, что линк сливает его творению, как-то не кажутся мне жизненными (для тех целей, для которых linq2sql создавался), сколько я на них не смотрю. LINQ2SQL конечно тоже не идеал, все таки первая версия, но вот фатальных косяков мне пока не встречалось, пока все довольно логично и вполне вписывается в мои сценарии.
Самый фатальный косяк, что я пока заметил, это очень большое время на генерацию SQL из LINQ выражения. Самый худший вариант — когда выражение большое и сложное, но базой выполняется довольно быстро — возможно замедление в несколько раз по сравнению с чистым ADO.NET. Смотрел в профайлере — некоторые методы в SqlProvider вызываются несколько сот тысяч раз за время одного преобразования . Странно, что не реализованно внутреннего кеширования для идентичных LINQ выражений — поскольку каждый раз выпольняется по сути идентичная работа. Компилируемые запросы конечно помогают, но они возможны не для всех типов выражений.
Здравствуйте, Sinix, Вы писали:
S>Гм. Ну как ни странно, мне казалось, что если "таблички мапятся на классы" — то эту уже нечто с претензией на ормапистость. И если что, с дизайнером как-то не игрались, всё честно — классы плюс attribute-mapping.
Так как ОО-программа по любому опирирует объктами, то отображение на классы безусловно необходимо. Точнее необходимо как-то задать соотвествие между записью в таблице и объектом олицитворяющим эту запись.
Но O/R-маперы занимаются далеко не только этим. Они пытаются сделать вид, что БД — это некое хранилише для объектов. Мол мы неким волшебным образом помещаем объекты в БД и извлекаем их от туда.
Именно тут и заключается основная разница. И Линк и распрастраненные O/R-маперы проводят соответствие между записью и объектом. Но Линк позволяет оперировать данными как набором списков объектов делая запросы к ним. А O/R-маперы эмулируют прозрачную сериализацию и загрузку объектов в память.
В общем, O/R-маперы пытаются сделать впечатление, что мы работаем с объектами хранящимися в памяти, а Линк просто позволяет запросить и обработать список данных.
Так что пробелмы в восприятии очевидны. Люди привыкшие к O/R-маперам считают само собой разумеющися когда у объектов есть коллекции подобъектов, а O/R-мапер автоматизирует получение данных из этих списков. А Линк действует совсем иначе. Он намного проще. В нем нет подобъектов. В нем есть прямое отображение таблиц на классы объектов, а понятий списков подобъектов в нем нет и в помине. Именно по этому Линк не O/R-мапер.
S>>Тогда бы стало очевидно, что за отложенной загрузкой, отсоединенным режимом работы с данными, сериализацией и прочими вещами надо идти в Entity Framework а не кувыркаться с Linq2Sql.
S>Гм. А зачем тогда оно там есть? Для Галочки?)
А где это они есть в Линке? Можно примеры или ссылочки?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Идея — да, да и ещё раз да. Я не собираюсь про это спорить. Я про конкретную реализацию. Я наверно даже не подозреваю, что тот кто её делал, слышал про "Лямбда исчисления Чёрча")
Не сомневайся, слышали. Они на работу взяли одного из разработчиков Хаскеля (самого фунционального языка).
S>Тут уже была куча холиваров... есть лямбды в 3-м шарпе, не есть лямбды... сколько можно?)
Как интересно! А можно ссылочку?
S>Тоже согласен. Но вот насчёт будущей доработанности LINQ for SQL сиильна сомневаюсь. Чтобы не быть голословным. Есть такой дяденька, Frans Bouma. Один из команды разработчиков платного ормаппера LLBLGen Pro. И вот в его блоге есть чудная-чудная история в девяти частях про прикручивания LINQ к их мапперу. Очень советую осилить, перед тем, как холиварить на тему LINQ.
Что я тут могу сказать. Будут пользователи массово просить, сделают эти джоины в следущей версии. Не будут, не сделают. Все просто.
S>Почему я привык к ООП? я как не странно не стараюсь написать свой "бизнес-объект" на каждый чих. До сих пор по старинке датасетами пользуемся)
Мне кажется, что Линк намного лучше датасетов.
S>Ну и насчёт нужных мне 20 строк. Если бы всё так просто было... Вы считаете что утянуть полтыщи строк за один раз и изредка их рефрешить куда медленнее, чем пихать при каждом скроле сервер тем же самым запросом, да ещё и с сортировкой (пусть и ограниченной с помощью top)?
Я считаю, что более разумно. Тратится меньше ресурсо, решение получается более простым и мастабируемым.
Сортировать же ничего не надо. Линк поддерживает страничный доступ на уровне синтаксиса.
S>И что вы все так сразу к мастер-детайлсам цепляетесь?) Если я скажу, что там не совсем мастер-детайлсы, это вас успокоит?)
Я не "мы". Я "прицепился" к 1000 строкам. Ну, не надо их тянуть. Эта идея кэширования и есть порождение бредовых идей O/R-мапинга. Зачем кэшировать данные где-то в промежуточном слое? Данные лучше всего обрабатывать средствами СУБД. А уж если кэшировать что-то, то как можно ближе к клиенту, чтобы эффктивность этого кэша была максимально эффектина. И лучше кэшировать не универсально и на всякий случай, а для решения конкретных задач производительности. Скажем закэшировать страничку со списком голосований и обновлять кэш только тогад когда список изменился. Сделать такое кэширование элементарно средствами веб-сервера. А вот кэшировать список голосований в памяти сервера приложений — это дурь вызванная подходами навязываемыми O/R-маперами. Все что унжно чтобы узнать изменился ли список — это мелкий запрос к БД возвращающий одно значение. А далее или отдаем страничку из кэша или перестраиваем ее.
VD>>Раздражают? На то есть уровни изоляции. Хотя разумнее не раздражаться, а расчитывать на это. Программы будут более мастабируемыми.
S>Таак. То есть, то, что клиент одновременно видит и устаревшие, и свежие данные — это уже преимущество?)
Как же ему удастся, то одновременно? Lazy load, это не более чем аналог однонаправленного курсора. Это и есть его влияние. Просто и для коллекций в памяти удается получить тот же результат за счет того, что Линковские фунции работающие с ними написаны с использованием итераторов (с yield-ами), а они автоматом обеспечивают этот самый отложенный доступ.
S>Ну и про уровни изоляции. Вы надеюсь не предлагаете держать serialized транзакцию, пока пользователь не проскролит по списку?)
Если это надо для логики, то никуда не денешся. Или перестраивай логику.
S>Угк. В общем я даже комментировать не хочу особо. Никогда не требовалось организовать удалённую обработку данных с последующим внесением изменений?) Так вот. LINQ for SQL в своём текущем состоянии этого не позволяет.
Можно пример, того о чем идет речь?
S>А я не негодую. Я делюсь наболевшим. Приятного холивара)
Почти уверен, что это не наболевшее, а результат неверного взгляда на средство. Ты думаешь, что это недоделанный O/R-мапер, а это интегрированные в язык запросы. Причем это даже не типизированные запросы к SQL-СУБД, а запросы которые могут быть преобразованны в SQL.
Плюсами технологии являются:
1. Тесная интеграция с ЯП.
2. Статическая типизация.
3. Абстрактный уровень повзоляющий сменой драйвера поддерживать новые СУБД.
4. Одинаковый синтаксис для разных источников данных (списки объектов, ХМЛ, БД и даже датасеты).
Недостатки:
1. Уровень абстрации не позволит использовать особенности конкретной СУБД.
2. Производительность запросов может хромать в некоторых случаях.
3. Своеобразный язык.
и т.п.
Надо взвесить "за" и "протим" и принять решение, что тебе лучше испоьзовать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Гм. Ну как ни странно, мне казалось, что если "таблички мапятся на классы" — то эту уже нечто с претензией на ормапистость. И если что, с дизайнером как-то не игрались, всё честно — классы плюс attribute-mapping.
Тут есть один тонкий момент, который на первый взгляд не очевиден. Дело в том, что основное предназначение этих "классы плюс attribute-mapping" — внести в ОО-программу типы, описывающие метаданные БД. При этом, в отличие от полновесных мепперов, создавать экземпляры этих классов совсем не обязательно. Это просто хранилище метаданных, но не описание runtime-представления данных в памяти.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Тут есть один тонкий момент, который на первый взгляд не очевиден. Дело в том, что основное предназначение этих "классы плюс attribute-mapping" — внести в ОО-программу типы, описывающие метаданные БД. При этом, в отличие от полновесных мепперов, создавать экземпляры этих классов совсем не обязательно. Это просто хранилище метаданных, но не описание runtime-представления данных в памяти.
И даже если они будут созданы, то это не чудо-объекты из ОРМ-систем которые по волшебству подгружают связанные объеты и записывают изменения обратно в БД. Это именно хранилища данных. Потому у народа и наступает разочарование, так как он думает, что это недоделанный ОРМ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: LINQ to SQL. первые разочарования.
От:
Аноним
Дата:
12.12.07 15:22
Оценка:
Здравствуйте, Curufinwe, Вы писали:
C> Компилируемые запросы конечно помогают, но они возможны не для всех типов выражений.
А можно об этом немного подробнее, для каких выражений не будет работать компиляция?
Здравствуйте, Curufinwe, Вы писали:
AVK>>На уровне синтаксиса не поддерживает. Take() и Skip() в query pattern не входят.
C>Они входят в System.Linq.Queryable
Это у нас уже называется "на уровне синтаксиса"?
C> точно также, как и всякие Select и Where. В чём разница то?
В том что они входят в query pattern, а этот самый query pattern захардкожен в компиляторе.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, <Аноним>, Вы писали:
А>а, если не секрет, каким образом позволяет?
DataContext.Attach()
А>Мы даже на платформе2008 у "эксперта" спрашивали и про EF и про LINQ,
А кто это был, если не секрет? Может просто вопрос не понял?
Здравствуйте, AndrewVK, Вы писали:
AVK>>>На уровне синтаксиса не поддерживает. Take() и Skip() в query pattern не входят.
C>>Они входят в System.Linq.Queryable
AVK>Это у нас уже называется "на уровне синтаксиса"?
C>> точно также, как и всякие Select и Where. В чём разница то?
AVK>В том что они входят в query pattern, а этот самый query pattern захардкожен в компиляторе.
Сглупил я конечно . Действительно на уровне этого "синтаксического сахара" поддержки нет, также как и многих других методов из Queryable.
Тем не менее ценность Take() и Skip() от этого не сильно уменьшается.
Здравствуйте, <Аноним>, Вы писали:
C>> Компилируемые запросы конечно помогают, но они возможны не для всех типов выражений.
А>А можно об этом немного подробнее, для каких выражений не будет работать компиляция?
После компиляции уже не может меняться форма SQL запроса, только значение параметров, поэтому нельзя использовать локальные коллекции:
var q = from o in db.Orders
where localCollection.Contains(o.OrderId) //будет runtime exception, т.к. на каждый элемент массива необходим свой параметр.select o;
По той же причине нельзя использовать метод Take(n) при работе с SQL2000, так как он не поддерживает параметризированный TOP. Даже если Вы подставите сюда константу, LINQ всё равно будет пытаться передать её в качестве параметра.
Ну и конечнонельзя использовать динамически сконструированные запросы. Хотя я пошёл на небольшую хитрость и сделал небольшой кеш динамических скомпилированных запросов, но эта реализация порой слишком усложняет код и его читаемость (как впрочем и использование скомпилированных запросов вообще).
Здравствуйте, AndrewVK, Вы писали:
C>> точно также, как и всякие Select и Where. В чём разница то?
AVK>В том что они входят в query pattern, а этот самый query pattern захардкожен в компиляторе.
Узнаю профи докапываться до слов. Суть высказывания не интересна, спорим об абстрактном.
Что до компилятора, то это его проблемы. Точнее тех кто его реализовывал. Тут вроде о Линке гворили. И о том, что есть готовый синтаксис получения страничного просмотра. Он специальным образом обрабатывается линковскими провайдерами и преобразуется в качественный SQL. Оствльнок — балшит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>В том что они входят в query pattern, а этот самый query pattern захардкожен в компиляторе.
VD>Узнаю профи докапываться до слов. Суть высказывания не интересна, спорим об абстрактном.
При чем тут слова? У тебя суть высказывания неверна. Нет в C# поддержки на уровне синтаксиса, совсем нет.
VD>Что до компилятора, то это его проблемы. Точнее тех кто его реализовывал. Тут вроде о Линке гворили. И о том, что есть готовый синтаксис получения страничного просмотра.
Нет никакого специального синтаксиса получения страничного просмотра.
VD> Он специальным образом обрабатывается линковскими провайдерами
Linq2SQL специальным образом обрабатывает string.Substring. И что, теперь у нас в шарпе есть готовый синтаксис получения подстроки?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>При чем тут слова? У тебя суть высказывания неверна. Нет в C# поддержки на уровне синтаксиса, совсем нет.
Можно мне привести цитату где я вообще хоть слово сказал про C#? Ты на нем просто зациклился.
VD>>Что до компилятора, то это его проблемы. Точнее тех кто его реализовывал. Тут вроде о Линке гворили. И о том, что есть готовый синтаксис получения страничного просмотра.
AVK>Нет никакого специального синтаксиса получения страничного просмотра.
Снова докапывашся до слов?
Есть синтаксис Skip и Take. Это встроенные возможности линка. То что в шарп их не встроили как ключевые слова еще не значит, что это не стандартная возмоность Линка. Вт в Васик они зашиты именно как ключевые слова (их даже среда подчеркивает):
Imports System
Module Module1
Sub Main()
Dim elems() As String = New String() {"Elem 1", "Elem 2", "Elem 3", "Elem 4", "Elem 5", "Elem 6", "Elem 7", "Elem 8"}
Dim query = From elem In elems Skip 4 Take 3
For Each x In query
Console.WriteLine(x)
Next
End Sub
End Module
Выведет:
Elem 5
Elem 6
Elem 7
VD>> Он специальным образом обрабатывается линковскими провайдерами
AVK>Linq2SQL специальным образом обрабатывает string.Substring. И что, теперь у нас в шарпе есть готовый синтаксис получения подстроки?
Я тебе еще не сказал, что мне на Шарп в общем-то плевать. Как язык мне больше нравится Немерле, а говорили мы о Линке который к Шарпу имеет только то отношение, что Шарп его поддериживает на ряду с другими языками.
Все что я пытался сказать, что есть стандартный, для линка, способ постраничного считывания данных (Я назвал это синтаксисом просто чтобы оперировать термином, а не черти чем). Что он вполне эффетивен и прост в использовании. И, что нет никакой нужды тащить из БД тысячи записей чтобы реализовать страничный просмотр. Ты же затеял спор на ровном месте только потому что захотел вставить свои 3 копейки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>> Мало ли что там кто на генерирует?
AVK>До генерации доходить не надо, достаточно посмотреть на свойства любого атрибута.
Неужели так трудно сказать, что там и как или дать ссылку? Мне просто некогда лазить по дизайнерам. Я даже пока не знаю где брать этот дизайнер и как открыть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Можно мне привести цитату где я вообще хоть слово сказал про C#? Ты на нем просто зациклился.
Ах да, про VB ты конечно знал
VD>Все что я пытался сказать, что есть стандартный, для линка, способ постраничного считывания данных
Стандартный для реализаций, построенных на Queryable, а не для линка.
VD> (Я назвал это синтаксисом просто чтобы оперировать термином, а не черти чем).
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, IB, Вы писали:
А>>а, если не секрет, каким образом позволяет? IB>DataContext.Attach()
ну, да и возня с сохранением оригинального значения
хотя это, видимо, и есть те недоделки о которых ты говорил
А>>Мы даже на платформе2008 у "эксперта" спрашивали и про EF и про LINQ, IB>А кто это был, если не секрет? Может просто вопрос не понял?
я не помню как его зовут.
Про Linq понятно, а EF объекты можно передавать через WCF?
Здравствуйте, AndrewVK, Вы писали:
VD>>Можно мне привести цитату где я вообще хоть слово сказал про C#? Ты на нем просто зациклился.
AVK>Ах да, про VB ты конечно знал
Что, задевает, что ты этого не знал?
Кстати, цитату ты так и не привел.
AVK>Стандартный для реализаций, построенных на Queryable, а не для линка.
Ты что казать то хотел?
ЗЫ
В следующий раз когда захочешь влезть в разговор делай это по смыслу, а не докапывайся до первых попавших слов. Глядишь будет больше конструктива.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Из сказанного там и по ссылкам я понял, что они отображают связи на "объектные ссылки" с целью упростить синтаксис джоинов и по совместительству позволяит просто извлекать сслочные объекты (которые при этом являются редактируемыми).
Честно говоря — это уже и есть уши ОРМ-ом. Я понимаю зачем это сделано. Это наверно удобно на практике, но это как раз концептуальная грязь которая и сбивает с мысли тех кто привык к ОРМ-ма. Так что решение, на мой взгляд, спорное. В прочем, если пользоваться этим делом с головой, то ничего страшного не будет.
AVK>Дизайнер брать не надо, он в студию встроен. Открыть тоже очень просто — добавляешь dbml файл в проект, оно и откроется.
Вот видишь, нужно хотя бы знать, что нужно добавлять dbml-файл. Я повозился и не понял этого сразу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
С>Обычно искусственно ставлю себе в этом случае планку — одно-два поля, не более, иначе — выделять в нормальных потомков. И то, такое решение (SingleTableInheritance) принимается на заключительных стадиях/витках проектирования.
Ну, вот видите Вы сами говорите, что при определенных условиях готовы использовать такой подход
Хотя принципиальной разницы — одно-два поля или пять-шесть практически нет.
Да, денормализация, ну и что? В первый раз что-ли Причем хочется отметить, что это не такая уж и страшная денормализация — просто для некоторых строк есть поля, которые всегда равны NULL.
Это все же не дублирование данных и не нарушение атомарности.
Вы-то кстати, во "втором способе" предлагаете чисто дублирование данных — вот это уж "настоящая" денормализация И это в общем, нормально!
С>Нет, как раз признак типа меня не пугает, он как раз таки обычно присутствует во всех типах наследования, хотябы как информационное поле. Меня пугает то, что творится внутри этой таблицы, и кстати, невозможность на уровне таблицы построить constaraint по полю потомка, который должен быть применим только для одного типа. Т.е. в случае SingleTableInheritance применяем constraint либо ко всем типам, либо вообще его не создаем и контролируем его в другом месте.
Да ничего там особо страшного "внутри этой таблицы" не творится...
И какой, например, constraint у вас не получается построить?
UNIQUE — вроде без проблем, FOREIGN — тоже, в CHECK добавите условие на тип...
А вот с другой таблицы поставить FOREIGN KEY на дочерний тип — и правда, не очень хорошо получится.
iT>>К хранению иерархии в одной таблице я тоже никогда не стремился. Было бы странно к этому стремиться. iT>>А вот использовать как один из самых простых и эффективных способов хранения — приходилось, равно как и другие. С>В любом подходе должна быть мера и здравый смысл, не так ли?
Абсолютно! Я просто хотел сказать, что и у этого способа есть свои плюсы, которые в каккой-то ситуации вполне могут перевешивать!
Я тоже не соглашусь с трактовкой MS, что это очень широко используемый подход, скорее всего, просто им с этого было легче начать (что понятно).
Но меня неприятно поразил ваш отзыв об этом способе, как об абсолютно неправильном и непригодном
Здравствуйте, Аноним, Вы писали:
А>ну, да и возня с сохранением оригинального значения А>хотя это, видимо, и есть те недоделки о которых ты говорил
В следующей версии должны появиться Connectionless DataContext.
А>я не помню как его зовут.
Просто, что-то я не припоминаю таких вопросов там, как эксперт..
А>Про Linq понятно, а EF объекты можно передавать через WCF? Они там обязательно должны быть от чего-то унаследованы, и насколько это все сериализуемо... Лично мне EF мало интересен, с практической точки зрения, поэтому я на него пристально и не смотрю. И вообще, его ребята из ObjectSpaces разрабатывали, так что до релиза он может и не дожить..
Мы уже победили, просто это еще не так заметно...
Re[11]: LINQ to SQL. первые разочарования.
От:
Аноним
Дата:
12.12.07 22:14
Оценка:
Здравствуйте, IB, Вы писали:
IB>В следующей версии должны появиться Connectionless DataContext.
супер, а хоть примерно известно когда будет?
А>>я не помню как его зовут. IB>Просто, что-то я не припоминаю таких вопросов там, как эксперт..
это точно не ты, тебя в тот момент не было
А>>Про Linq понятно, а EF объекты можно передавать через WCF? IB> Они там обязательно должны быть от чего-то унаследованы, и насколько это все сериализуемо...
вот-вот IB> Лично мне EF мало интересен, с практической точки зрения, поэтому я на него пристально и не смотрю.
а можешь сказать, что ты используешь как ORM? и как объекты передаёшь клиенту?
Извиняюсь, что долго не было. Работа, чтоб её) Некрасиво как-то получается. Оставил флейм на четыре страницы и ушёл...
S>Хамить? На "ты" обиделся, или на то что я упрекаю тебя в недостаточном знании предмета? Хорошо, перейду на вы. S>Я (и не только я один) просто констатирую факт того, что вы не достаточно разобравшись с предметом пытаетесь использовать его не по назначению и при этом делаете категорические выводы. S>Вы пытаетесь молотком забивать шурупы и при этом отчаянно ругаетесь на то, что они не похожи на гвозди.
Уггуг. То есть я правильно понял, что LINQ2SQL сейчас не позиционируется как ормаппер?
В таком случае меня явно ввела в залуждение куча постов, с утверждениями в духе "DLINQ is simple O/R mapping tool" ещё во времена успешно несданного object spaces. Первый найденный сабж. Во всяком случае, части ормаппера там точно есть (те же EntitySet<> для подсписков), маппинг к наследованным классам и тд и тп.
В таком случае действительно все мои претензии выглядят немного странно. Насчёт обиделся — мне почему-то не нравится, когда в ответ на пост на тему, с которой по... гм... пожил пару месяцев (это не считая "читать кучу доков") мне заявляют, что я просто ничего не знаю. Обидно же)
И насчёт категорических выводов. Я же ещё в первом посте отписался, что идея — хорошая. Реализация — сырая.
S>>Например, такая весёлая агитационная дока "Админам СУБД про entity framework" где английским по белому идёт следующее:
S>>The above LINQ query looks a lot like something you would write in T-SQL (odd syntax notwithstanding), but actually, you are writing to the conceptual model. What does this mean? This means that you now have more control over the database!
S>Я читал это. Редкостный бред...
Согласен. Проблема в том, что этот бред отписан в официальном мелкософтовском блоге. Это ж не я придумал)
S>Ну, так это не моя трактовка, а тех кто делает EF. Можете их урекать, что они в детстве мало Дейта читали S>Эти ребята оперируют треминами "The Conceptual Model" и "The Storage Model". Чего флеймить? Откройте help по EF и почитайте. Они разрабатывают фрэймворк кторым мы пользуемся, и поэтому они диктуют терминологию а не мы. Вы создайте собственный движок и можете оределять там термины, как вам нравится.
Угу. Просто ухмыльнуло нечаянно, когда услышал, что физической моделью называют уже БД. А когда-то даже "файл с записями" рассматривался как пошлая абстракция, не дающая вникнуть в детали реализации. Печально...
S>>>Тогда бы стало очевидно, что за отложенной загрузкой, отсоединенным режимом работы с данными, сериализацией и прочими вещами надо идти в Entity Framework а не кувыркаться с Linq2Sql.
S>>Гм. А зачем тогда оно там есть? Для Галочки?)
S>В точку, только пожалуй "галочка" — с маленькой буквы . Но, я заюзал бы System.Data.Linq вместо System.Data.Entity в каком нибудь небольшом web приложении или интерактивном прототипе. Очень удобные там вещи есть, вроде выведения типов и строгой типизации в запросах.
Угу.
S>>> Выгружать тысячи записей master/details было модно и нужно в давние времена клиент серверных архитектур (которые по этим причинам и почили в бозе), а для масштабируемых приложений так делать не принято. и т.д и т.п.
S>>Ы) мы почили в бозе, мы почили в бозе, мы почили в бозе... S>>Вы с файл-серверными приложениями не путаете часом? Хотя и они ещё живы. Та же 1С... S>Живы конечно. У бизнес приложений долгая жизнь. Я говорил об архитектуре а не оприложениях. Разницу улавливаете?
Архитектура — кучу раз да. Но это уже ближе к религии. Немного забавно, что компьютеры всё быстрее, а объёмы передаваемых данных всё меньше и меньше. Чую лет так через дцать будут удивляться, что люди до сих пор гоняют по сети целые строки.
S>>Не настораживает сортировка по всем полям и захардкоденная последовательность соединений из-за лефтжойнов??? S>Нет, не настораживает, это же кодогенератор. S>Возможно я не стал бы использовать эту штуку в высоконагруженной системе, и то только после соответствующих нагрузочных тестов. Не имею привычки заниматься преждевременной оптимизацией.
Ну... ну вот не люблю я собственными руками вносить в систему узкие места. Но если LINQ не позиционитруется в качестве light-weight DAL, то требовать от него производительности как-то глупо...
S>>>Недавно, кстати прочитал где то в блогах что в команду EF специально откомандировали лучших спецов по оптимизации запросов из SQL Server core team.
S>>Ссылку. S>Найду, скину.
Плиз. Что-то не нашёл. Руки кривые. Или гугль меня не понимает...
S>>Удачи. И не хамите, пожалуйста. Читать неприятно) S>Ваши пассажи тоже читать не очень приятно. В исходном сообщении вы в достаточно хамской форме упрекаете разработчиков LINQ в непонимании SQL, а когда в непонимании LINQ упрекают вас, то вы вспоминаете об этикете. Ведите себя соответственно и не будет поводов для обид.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinix, Вы писали:
S>>Идея — да, да и ещё раз да. Я не собираюсь про это спорить. Я про конкретную реализацию. Я наверно даже не подозреваю, что тот кто её делал, слышал про "Лямбда исчисления Чёрча")
VD>Не сомневайся, слышали. Они на работу взяли одного из разработчиков Хаскеля (самого фунционального языка).
Уху. Не знал. Хотя теперь понятно откуда ноги у лямбд, анонимных типов и extension methods.
Крайне полезные штуки. И про реализацию... я ж ничего не говорил про все остальные диалекты LINQ... Потому как не копался глубоко. Единственное что могу вспомнить из обоснованных нападок — претензии Франса Боумы про IQueryable/IQueryProvider и про парсинг ExpressionTree. Хотя человек небеспристрастный, но читать забавно.
S>>Тут уже была куча холиваров... есть лямбды в 3-м шарпе, не есть лямбды... сколько можно?)
VD>Как интересно! А можно ссылочку?
Первое что нашлось. Не совсем РСДН (наверное поэтому и страниц всего 6).
S>>Почему я привык к ООП? я как не странно не стараюсь написать свой "бизнес-объект" на каждый чих. До сих пор по старинке датасетами пользуемся)
VD>Мне кажется, что Линк намного лучше датасетов.
Гм. Ну, наверно мы по-разному их готовим. Как-то не приходилось реализовывать проекции, сложными запросы и прочее на стороне клиента. Зачем, если со всем этим неплохо справляется сервак? Если его дёргать как можно реже, конечно.
VD>Я не "мы". Я "прицепился" к 1000 строкам. Ну, не надо их тянуть. Эта идея кэширования и есть порождение бредовых идей O/R-мапинга. Зачем кэшировать данные где-то в промежуточном слое? Данные лучше всего обрабатывать средствами СУБД. А уж если кэшировать что-то, то как можно ближе к клиенту, чтобы эффктивность этого кэша была максимально эффектина. И лучше кэшировать не универсально и на всякий случай, а для решения конкретных задач производительности. Скажем закэшировать страничку со списком голосований и обновлять кэш только тогад когда список изменился. Сделать такое кэширование элементарно средствами веб-сервера. А вот кэшировать список голосований в памяти сервера приложений — это дурь вызванная подходами навязываемыми O/R-маперами. Все что унжно чтобы узнать изменился ли список — это мелкий запрос к БД возвращающий одно значение. А далее или отдаем страничку из кэша или перестраиваем ее.
Гм... Я вроде ничего не говорил, что у нас апп-сервер где-то присутствует. Не понадобился как-то...
Угу. Очевидно, мы просто не поняли друг друга.
S>>Таак. То есть, то, что клиент одновременно видит и устаревшие, и свежие данные — это уже преимущество?)
VD>Как же ему удастся, то одновременно? Lazy load, это не более чем аналог однонаправленного курсора. Это и есть его влияние. Просто и для коллекций в памяти удается получить тот же результат за счет того, что Линковские фунции работающие с ними написаны с использованием итераторов (с yield-ами), а они автоматом обеспечивают этот самый отложенный доступ.
Ну как тебе сказать... В общем смысл такой: биндим Query<T> напрямую к какому-нибудь списку. Обновляем данные. Скроллим. В части списка устаревшие данные. В части — свеженькие. Разумеется, если не делать serializable транзакций или предваврительной загрузки.
S>>Угк. В общем я даже комментировать не хочу особо. Никогда не требовалось организовать удалённую обработку данных с последующим внесением изменений?) Так вот. LINQ for SQL в своём текущем состоянии этого не позволяет.
VD>Можно пример, того о чем идет речь?
Уже вроде обсудилось без меня...
S>>А я не негодую. Я делюсь наболевшим. Приятного холивара)
S>>>>Недавно, кстати прочитал где то в блогах что в команду EF специально откомандировали лучших спецов по оптимизации запросов из SQL Server core team.
S>>>Ссылку. S>>Найду, скину.
S>Плиз. Что-то не нашёл. Руки кривые. Или гугль меня не понимает...
Вспомнил. Об этом говорил в своем докладе "Интегрированные в язык запросы (LINQ) в Microsoft Visual Studio 2008" на Платформе 2008 Роман Здебский. Запись доклада можно скачать здесь (надо регистрироваться на сайте)
S>Гм. Ну, наверно мы по-разному их готовим. Как-то не приходилось реализовывать проекции, сложными запросы и прочее на стороне клиента. Зачем, если со всем этим неплохо справляется сервак? Если его дёргать как можно реже, конечно.
Правильный ход мысли. Все запросы нужно передавать на сервак.
Вот только есть несколько "но":
1. Логика размазывается по нескольким местам. Некоторые считают это преимуществом, но реально это преимущество работает только в очень узких наборах сценариев. В моей практике 99% изменений в требованиях приводили к необходимости править всю вертикаль слоев — от гуи до таблиц БД. Чем больше в промежутке слоев, тем больше тупой работы.
2. SQL плохо подходит для описания запросов с переменной структурой. Тривиальные (с точки зрения пользователя) PIVOT или изменения критериев сортировки невозможно выполнить в рамках одного параметризованного стейтмента. В итоге народ идет одним из двух путей:
а) Dynamic SQL на сервере. Не очень эффективная штука, с учетом того, что T-SQL (не могу 100% судить о других диалектах) плохо подходит для императивных операций. Низкая производительность и чувствительность к ошибкам — динамический SQL хранится в строковых константах и не проверяется вплоть до рантайма. В итоге можно получить экзотическое сочетание параметров хранимки, при котором в аутпут попадает два AND подряд или что-то в этом роде, и на этом щасте заканчивается.
б) динамический SQL на клиенте. С точки зрения производительности это чуть получше, но с точки зрения отладки и чувствительности к изменениям — еще хуже, чем T-SQL.
Linq позводяет реализовывать проекции, сложные запросы и прочее на стороне клиента. При этом компилятор следит за корректностью статически. Но выполнение запроса делегируется серверу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
iT>Вы-то кстати, во "втором способе" предлагаете чисто дублирование данных — вот это уж "настоящая" денормализация И это в общем, нормально!
Какое дублирование данных ты имеешь в виду во втором способе? Дублирования кортежей здесь нет, а дублирование атрибутов в таблицах-потомках без дублирования кортежей еще не означает дублирование данных. iT>А вот с другой таблицы поставить FOREIGN KEY на дочерний тип — и правда, не очень хорошо получится.
На дочерний как раз получится, на базовый — нет.
Потом, как известно, шировко распространено два варианта контроля ссылочной целостности — на foreign key и на триггерах. К тому же второй способ — это скорее "оптимизационный" вариант.
>>SingleTableInheritance iT>Но меня неприятно поразил ваш отзыв об этом способе, как об абсолютно неправильном и непригодном
Не как о абсолютно неправильным, а о котором слудует вспомнтить в последнюю очередь. И там где 5-6 полей относящихся к разным потомкам, я уж точно его использовать не буду.
S>1. Логика размазывается по нескольким местам. Некоторые считают это преимуществом, но реально это преимущество работает только в очень узких наборах сценариев. В моей практике 99% изменений в требованиях приводили к необходимости править всю вертикаль слоев — от гуи до таблиц БД. Чем больше в промежутке слоев, тем больше тупой работы.
Тупую работу пусть делают генераторы кода по моделям. К тому же прегенерить k слоев из n в этом случае порой оказывается гораздо легче, чем найти от чего оттолкнуться в ином случае.
S>2. SQL плохо подходит для описания запросов с переменной структурой. Тривиальные (с точки зрения пользователя) PIVOT или изменения критериев сортировки невозможно выполнить в рамках одного параметризованного стейтмента.
изменение сортировки параметром:
--set @sortIndex = 2
select f1,f2,f3 from tb order by ISNULL(@sortIndex,1)
PIVOT — смотря для чего?
Для вывода в gui — xslt, по-моему проще не куда...
Для анализа, по-моему в таких случаях лучше сразу на OLAP завязаться, чем pivot-ы писать.
Кстати, для создания PIVOT в mssql 2005 есть синтакис, правда в ряде случаев этот встроенный pivot не подходит, поэтому люди продолжают обходиться другими способами.
Здравствуйте, снежок, Вы писали:
С>Меня на самом деле вот что настораживает — как бы каждый "индус по призванию" не начал LINQ-запросы лепить везде где не попади в целях сверхбыстрого создания кода "сверхнового поколения".
А шо, до появления LINQ "индусов по призванию" не было? Меня вон Reflection и то больше настораживает. Чего там тока профессиональный индус не налабает с ним...
Здравствуйте, снежок, Вы писали: С>изменение сортировки параметром: С>--set @sortIndex = 2 С>select f1,f2,f3 from tb order by ISNULL(@sortIndex,1)
А теперь покажи мне как ее сделать desc, как сделать сложную сортировку.
С>PIVOT — смотря для чего?
Как для чего? Для преобразования данных. С>Для вывода в gui — xslt, по-моему проще не куда... С>Для анализа, по-моему в таких случаях лучше сразу на OLAP завязаться, чем pivot-ы писать.
Во многих случаях OLAP это оверкилл. XSLT тоже подходит, знаете ли, не всегда. С>Кстати, для создания PIVOT в mssql 2005 есть синтакис, правда в ряде случаев этот встроенный pivot не подходит, поэтому люди продолжают обходиться другими способами.
Кстати, я в курсе про PIVOT в 2005. И у него точно такие же ограничения, как и у dynamic T-SQL решения, которое я постил на RSDN года три или четыре тому назад. Только производительность получше.
Я же говорю — Linq это и есть тул для генерации SQL по модели. Причем очень неплохой тул.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали:
А>супер, а хоть примерно известно когда будет?
А>а можешь сказать, что ты используешь как ORM? и как объекты передаёшь клиенту?
Как ORM я не использую ничего..
В качестве маппера по возможности стараюсь использовать BLT
. Поскольку мои объекты с данными, как правило, не содержат логики, то никакого специального DTO для передачиклиенту изобретать не приходится, прямо их и передаю..
Здравствуйте, Sinclair, Вы писали:
S>Linq позводяет реализовывать проекции, сложные запросы и прочее на стороне клиента. При этом компилятор следит за корректностью статически. Но выполнение запроса делегируется серверу.
А почему собственно только на сервере? Весь кайф абстрации запроса в том, что он одинаково выглядит (и пишется) независимо от того как его будут исполнять. Его даже над датасетами можно применять.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, снежок, Вы писали: С>>изменение сортировки параметром: С>>--set @sortIndex = 2 С>>select f1,f2,f3 from tb order by ISNULL(@sortIndex,1) S>А теперь покажи мне как ее сделать desc, как сделать сложную сортировку.
Чисто теоритически могу сделать и показать практически любую параметризованную сортировку по asc/desc и без динамического TSQL и без подготовки нескольких вариантов запросов, лишь бы порядок следования столбцов не был переменным (приз будет ?). Практически — чаще хватает варианта приведенного выше.
Согласен, что некоторые ограничения и рутинность присутствуют, но утверждать что сложная параметризованная сортировка совсем невозможна без динамического sql... хм...
use master
declare @sortDirect1 int
declare @sortDirect2 int
declare @xml varchar(8000)
declare @idoc int
--параметры и дирекшин для сортировкиset @xml = '<root>
<sort ColumnIndex="1" Sort="asc" />
<sort ColumnIndex="2" Sort="desc" />
</root>'
exec sp_xml_preparedocument @idoc out, @xml
create table #sort(
ColumnIndex int
,Sort varchar(4)
)
insert into #sort(ColumnIndex, Sort)
select ColumnIndex, Sort
from OPENXML(@idoc, '/root/sort')
with (
ColumnIndex int '@ColumnIndex'
,Sort varchar(4) '@Sort'
)
select @sortDirect1 = ColumnIndex from #sort where ColumnIndex = 1 and Sort = 'desc'
select @sortDirect2 = ColumnIndex from #sort where ColumnIndex = 2 and Sort = 'desc'
select
name
,object_id
from sys.all_objects
order by
CASE @sortDirect1 WHEN 1 THEN '0' ELSE name END
,ISNULL(@sortDirect1, '1') desc
,CASE @sortDirect2 WHEN 2 THEN 0 ELSE object_id END
,ISNULL(@sortDirect2, '1') desc
exec sp_xml_removedocument @idoc
drop table #sort
S>Кстати, я в курсе про PIVOT в 2005. И у него точно такие же ограничения, как и у dynamic T-SQL решения, которое я постил на RSDN года три или четыре тому назад. Только производительность получше.
Я думаю на sql.ru pivot на dynamic sql, плюсы и минусы постили гораздо раньше...
S>Я же говорю — Linq это и есть тул для генерации SQL по модели. Причем очень неплохой тул.
Ну вообщем, пока по обсуждению я вижу что мнения на счет "очень неплохой тул для генерации SQL" разделились...
iT>>А вот с другой таблицы поставить FOREIGN KEY на дочерний тип — и правда, не очень хорошо получится. С>На дочерний как раз получится, на базовый — нет.
Как это?? На базовый — просто обычный FOREIGN KEY на общий PK
С>Потом, как известно, шировко распространено два варианта контроля ссылочной целостности — на foreign key и на триггерах. К тому же второй способ — это скорее "оптимизационный" вариант.
На триггерах — тоже никаких проблем. Ну, добавится еще везде условие на конкретный тип.
Здравствуйте, Igor Trofimov, Вы писали: iT>Как это?? На базовый — просто обычный FOREIGN KEY на общий PK
Это для варианта наследования в виде связи 1-к-1, но мы же в последнем посте обсуждали другой вариант — наследования всех атрибутов базовой сущности. В этом варианте внешнего ключа на базовую сущность быть не может, так как в базовой таблице не содержится ничего относящегося к дочерним типам. Видимо ты не совсем правильно понимаешь этот тип наследования или я что то не так объяснил.
С>>Потом, как известно, широко распространено два варианта контроля ссылочной целостности — на foreign key и на триггерах. К тому же второй способ — это скорее "оптимизационный" вариант.
iT>На триггерах — тоже никаких проблем. Ну, добавится еще везде условие на конкретный тип.
Я о том что вариант контроля ссылочной целостности на триггерах — чаще для "второго" типа наследования.
Здравствуйте, снежок, Вы писали:
С>Здравствуйте, Sinclair, Вы писали: S>>Здравствуйте, снежок, Вы писали: С>>>изменение сортировки параметром: С>>>--set @sortIndex = 2 С>>>select f1,f2,f3 from tb order by ISNULL(@sortIndex,1) S>>А теперь покажи мне как ее сделать desc, как сделать сложную сортировку.
С>Чисто теоритически могу сделать и показать практически любую параметризованную сортировку по asc/desc и без динамического TSQL и без подготовки нескольких вариантов запросов, лишь бы порядок следования столбцов не был переменным (приз будет
Не будет приза. Оптимизатор не сможет построить вменяемый план по такому запросу. Как только ты сделал complex expression в order by — добро пожаловать в сортировку в памяти. А прямой SQL позволяет воспользоваться индексом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>А почему собственно только на сервере? Весь кайф абстрации запроса в том, что он одинаково выглядит (и пишется) независимо от того как его будут исполнять. Его даже над датасетами можно применять.
Совершенно верно. На мой вкус, весь кайф как раз в том, что нет подводных камней. Нет ограничения на место исполнения, в том числе можно полностью отдать его в удаленный сервер без потери строгости типизации и прочих прелестей статического контроля.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: LINQ to SQL. первые разочарования.
От:
Аноним
Дата:
14.12.07 15:09
Оценка:
Здравствуйте, IB, Вы писали:
А>>а можешь сказать, что ты используешь как ORM? и как объекты передаёшь клиенту? IB>Как ORM я не использую ничего.. IB>В качестве маппера по возможности стараюсь использовать BLT
. Поскольку мои объекты с данными, как правило, не содержат логики, то никакого специального DTO для передачиклиенту изобретать не приходится, прямо их и передаю..
понятно. спасибо за информацию
S>Не будет приза. Оптимизатор не сможет построить вменяемый план по такому запросу. Как только ты сделал complex expression в order by — добро пожаловать в сортировку в памяти. А прямой SQL позволяет воспользоваться индексом.
Ты утверждал что нельзя сделать desc и сложную cортировку без динамического sql.
О сравнении планов речь не шла, речь шла о функционале.
Здравствуйте, снежок, Вы писали: С>Ты утверждал что нельзя сделать desc и сложную cортировку без динамического sql. С>О сравнении планов речь не шла, речь шла о функционале.
Не, ну если хочешь — я признаю, что ты немерено крут, а я облажался.
Суть вопроса это не изменит — TSQL получается ужасным и плохо обобщаемым. Кроме того, отлаживать все эти ISNull, обращения ключа и прочие извращения тоже не радость.
Linq по-прежнему позволяет писать гораздо более компактный, надежный и высокопроизводительный код.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Не, ну если хочешь — я признаю, что ты немерено крут, а я облажался.
Не надо сарказма, какие требования — такой и результат
S>Суть вопроса это не изменит — TSQL получается ужасным и плохо обобщаемым. Кроме того, отлаживать все эти ISNull, обращения ключа и прочие извращения тоже не радость.
Это дело вкуса и привычки, я вот например с ужасом вспоминаю времена когда мне приходилось рефакторить один access-проект мигрированный под mssql. И пока не появился нормальный слой xп и DAL, отладка этого проекта была сущим адом. В профайлере нихрена не было понятно что откуда и почему. Просиживание в VS под отладкой занимало почти весь рабочий день. Запросы постоянно приходилось править и после каждого протестированного исправления — перекомпиляция и выкладывание сборки на сервак. Нет, ну может конечно есть люди спокойно позволяющие себе кидать сборку на сервер по 10 раз в день, отрубая всех, в моих проектах — нет. Ну и что из того что linq-запрос объектный? Сути это не меняет тоже!
Есть девелоперы которые плохо знают t-sql, но есть и еще больше появится девелоперов которые плохо знают linq или применяют его неверно и получим все то же самое, что было раньше c проектами на access-е и fox-е. Все это уже было...
Я вообще не понимаю откуда у вроде бы опытных людей столько оптимизма по поводу новой подделки, которую опять пытаются втюхать через маркетинг?
"Подождите выхода EDF — там все круто"
,"Подождите выхода Astoria — все проблемы с сервисами решаться сами собой"
,"Подождите выхода EDF 2.0 (года через 2, раньше не можем потому что он написан на C# 4.0 и под FW 4.0 где используются супермегапродвинутые дженерики и паралельный linq)"
,"Купите новую VS потому что под старой разрабатывать для FW 4.0 нельзя"
,"Купите новый MSSQL, потому что там новый наикрутейший спермега оптимизатор, справляющийся с любым тупорыло-написанным запросом LINQ".
...список можно продолжить.
S>Linq по-прежнему позволяет писать гораздо более компактный, надежный и высокопроизводительный код.
Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером.
И я бы сказал "надеюсь что linq позволит писать гораздо более компактный, надежный и высокопроизводительный код", но пока еще не позволяет, к сожалению. И наличие повсюду LEFT OUTER JOIN-ов и count-ов об этом свидетельствует.
iT>>Как это?? На базовый — просто обычный FOREIGN KEY на общий PK С>Это для варианта наследования в виде связи 1-к-1, но мы же в последнем посте обсуждали другой вариант — наследования всех атрибутов базовой сущности. В этом варианте внешнего ключа на базовую сущность быть не может, так как в базовой таблице не содержится ничего относящегося к дочерним типам. Видимо ты не совсем правильно понимаешь этот тип наследования или я что то не так объяснил.
Я вообще-то отвечал на это:
С>Меня пугает то, что творится внутри этой таблицы, и кстати, невозможность на уровне таблицы построить constaraint по полю потомка, который должен быть применим только для одного типа. Т.е. в случае SingleTableInheritance применяем constraint либо ко всем типам, либо вообще его не создаем и контролируем его в другом месте.
и я говорил, что все констрейнты как раз отлично строятся в случае SingleTable
Здравствуйте, Sinclair, Вы писали: S>Совершенно верно. На мой вкус, весь кайф как раз в том, что нет подводных камней. Нет ограничения на место исполнения, в том числе можно полностью отдать его в удаленный сервер без потери строгости типизации и прочих прелестей статического контроля.
Да, да... нет ограничения на место исполнения...
Теперь представь себе следующую ситуацию, вовсе не редкую, кстати:
У тебя появляется хороший продукт с хорошим функционалом, оракловая БД, промежуточный уровень и интерфейс под .net-ом, работа с БД через linq to oracle, написанный самим ораклом. Все идет не плохо.
Появляется немецкий клиент/партнер, который готов заплатить крупные бабки за продукт и его поддержку.
Шев в восторге, манагеры довольны собой и предвкушают сладкую жизнь...
Единственное что не устраивает клиента — это .net, потому что немцы ох как не любят ms, просто принципиально, и везде хотят java.
У них же, кхе, стандарты корпоративные и транснациональные...
Шеф идет к тебе с вопросом "А можешь? Только они не хотят всяких серверов интеграций, обмена сообщениями, сервисов. Говорят накушались, хватит. Хотят сквозное решение".
Ты — конечно могу, только мне надо повыковыривать изо всех дыр все linq-запросы и прикладной код на основе его и запихнуть во что то иное (stored proc, java stored proc, NHibernate...) потому что linq под явой нету, потом для этого нового кода написать новые unit-тесты и еще кучу всего. Вообщем для нашего наикрутейшего продукта с учтетом того, что надо нанять еще несколько человек в группу, это займет года 2... наверное...
Шеф — "А зачем ты на этот самый..., как его..., лин-ку заточился, ведь есть же проверенные временем решения, паттерны, слои и т. п. Сейчас бы проще было!"
Ты — "А я думал он решит все наши проблемы, сократит написание рутинного кода, стоимость разработки, потом это ж стильно модно, молодежно ".
Шеф — "Понятно, в итоге мы не можем удовлетворить меняющиеся бизнес-требования, не можем поднять продажи и заработать бабла..."
Здравствуйте, снежок, Вы писали:
С> И пока не появился нормальный слой xп и DAL, отладка этого проекта была сущим адом.
Это вопрос архитетуры, а не используемой библиотеки...
С> Запросы постоянно приходилось править и после каждого протестированного исправления — перекомпиляция и выкладывание сборки на сервак. Нет, ну может конечно есть люди спокойно позволяющие себе кидать сборку на сервер по 10 раз в день, отрубая всех, в моих проектах — нет.
У тебя все проекты правятся по живому? Что тебе мешает все 10 раз посмотреть что происходит на тестовом сервере и выложить в VCS при уходе с работы что получилось, никому не мешая?
C>Ну и что из того что linq-запрос объектный? Сути это не меняет тоже!
Хором тебе уже говорят, что запрос ни разу не объектный, а очень даже реляционный.
С>Я вообще не понимаю откуда у вроде бы опытных людей столько оптимизма по поводу новой подделки,
Наверное неспроста..
С>Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером.
Помнится, когда-то тоже самое говорили про ассемблер.
С> И наличие повсюду LEFT OUTER JOIN-ов и count-ов об этом свидетельствует.
Наличие LEFT JOIN-ов и COUNT-ов не свидетельствует ни о чем...
Здравствуйте, снежок, Вы писали:
С>Теперь представь себе следующую ситуацию,
Бред.
С> вовсе не редкую, кстати:
=)
С>Ты — конечно могу, только мне надо повыковыривать изо всех дыр все linq-запросы и прикладной код на основе его
Что это за "прикладной код на основе"?
Если даже, вдруг, такое случилось, и тебе действительно надо избавиться от .Net, то переписывание запросов будет наименьшей из проблем.
С>> И пока не появился нормальный слой xп и DAL, отладка этого проекта была сущим адом. IB>Это вопрос архитетуры, а не используемой библиотеки...
Правильно, только вот ваш хваленный linq так и подталкивает вновь все размазывать по слоям, вместо того чтобы иметь вменяемую архитектуру. С>> Запросы постоянно приходилось править и после каждого протестированного исправления — перекомпиляция и выкладывание сборки на сервак. Нет, ну может конечно есть люди спокойно позволяющие себе кидать сборку на сервер по 10 раз в день, отрубая всех, в моих проектах — нет. IB>У тебя все проекты правятся по живому? Что тебе мешает все 10 раз посмотреть что происходит на тестовом сервере и выложить в VCS при уходе с работы что получилось, никому не мешая?
В первое время ошибки требовалось править оперативно и сразу выкладывать одно исправление за другим. Такова уж была специфика проекта и его состояние.
C>>Ну и что из того что linq-запрос объектный? Сути это не меняет тоже! IB>Хором тебе уже говорят, что запрос ни разу не объектный, а очень даже реляционный.
Хором тебе уже готовы кричать, что реляционный он на сервер приходит, а в .net-коде выглядит как подобие объектного, который не каждый сейчас способен граммотно написать.
С>>Я вообще не понимаю откуда у вроде бы опытных людей столько оптимизма по поводу новой подделки, IB>Наверное неспроста..
Да, не спроста, потому что ms, потому что встроили в свой продукт, потому что маркетологи покричали, блогеры попиарили.
Нет, я вовсе не против идеи как таковой. Удобно для работы с коллекциями.
Но для работы с БД... дайте нормальный родной маппер на хп + bo-библиотеку с биндингом, мне больше ничего не надо. Пусть остальные работаю как им нравится, мне по-фигу, как и остальным на мои проверенные временем подходы.
А так я и до этого в инете мог наковырять с десяток ORM(или назовите как хотите) выполняющих такую же лабуду.
С>>Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером. IB>Помнится, когда-то тоже самое говорили про ассемблер.
Помнится когда-то говорили что программы будут писать роботы, а программисты вымрут как динозавры.
Помнится предрекали светлое будущее MDA, еще много чего помнится...
С>> И наличие повсюду LEFT OUTER JOIN-ов и count-ов об этом свидетельствует. IB>Наличие LEFT JOIN-ов и COUNT-ов не свидетельствует ни о чем...
Т.е. не будем заморачиваться, просто нагенерим везде внешних соединений, даже если хватает или должо быть внутреннее и все ок? Так да?
С>>Теперь представь себе следующую ситуацию, IB>Бред.
Бред воспринимать очень сырой продукт как очередную панацею, и повсеместно пиарить его.
С>>Ты — конечно могу, только мне надо повыковыривать изо всех дыр все linq-запросы и прикладной код на основе его IB>Что это за "прикладной код на основе"?
Как пить дать, столкнешся где-нибудь с намешанной бизнес-логикой с linq-запросами, тогда поговорим. IB>Если даже, вдруг, такое случилось, и тебе действительно надо избавиться от .Net, то переписывание запросов будет наименьшей из проблем.
Был бы слой хп изначально, не пришлось бы переписывать запросы вообще.
Даже в ситуации смены субд, перегенирировать crud и вручную написанные запросы (например для отчетов) вызвало бы меньше проблем если бы все было оформлено в хп .
Здравствуйте, снежок, Вы писали: С>Бред воспринимать очень сырой продукт как очередную панацею, и повсеместно пиарить его.
Бред воспринимать позитивные отзывы об очень перспективном продукте как совет немедленно всё бросить и очертя голову переписать всё на нем. Рамки применения Linq2Sql хорошо известны. Вы вообше всю рекламу по телевизору воспринимаете как личное оскорбление? Вон ford fusion оголтелую рекламную кампанию развернул; может попробуем убедиться, что он — говно, путем запихивания в него фундаментного блока? А то иш чо — "вместительным" обозвали. Продукт-то сырой!
С>Как пить дать, столкнешся где-нибудь с намешанной бизнес-логикой с linq-запросами, тогда поговорим.
Ну, вот это я могу понять. Сам я опыта применения линка в масштабных проектах не имею, поэтому о влиянии его на архитектуру в целом судить опасаюсь. Но попробовать хочется. IB>>Если даже, вдруг, такое случилось, и тебе действительно надо избавиться от .Net, то переписывание запросов будет наименьшей из проблем. С>Был бы слой хп изначально, не пришлось бы переписывать запросы вообще. С>Даже в ситуации смены субд, перегенирировать crud и вручную написанные запросы (например для отчетов) вызвало бы меньше проблем если бы все было оформлено в хп .
Вообще-то ты говорил не о ситуации смены СУБД, а о смене дотнета. Не увиливай. Переписать приложение с дотнета на джаву сложно независимо от того, есть у тебя ХП или Linq. Я, конечно, допускаю, что у тебя есть подобный опыт, но если честно, то с трудом. Вот у нас есть продукт существующий в двух code bases — С# и PHP. Ну так стоимость "конверсии" приблизительно равна стоимости написания с нуля. Так что я бы попросил без ля-ля.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
С>>Был бы слой хп изначально, не пришлось бы переписывать запросы вообще. С>>Даже в ситуации смены субд, перегенирировать crud и вручную написанные запросы (например для отчетов) вызвало бы меньше проблем если бы все было оформлено в хп . S>Вообще-то ты говорил не о ситуации смены СУБД, а о смене дотнета. Не увиливай.
Да я и не увиливаю, просто предположил что можно было бы задать вопрос о поддержке совместимости с несколькими субд.
т.е. другая сторона вопроса (в противовес вопросу .net to java). Вот и высказался не дожидаясь.
>>Так что я бы попросил без ля-ля.
Если изначально такие требования ставятся, то далеко не все так грустно может быть.
Методы для этого есть — аспектное программирование, case-tools и генераторы.
Но если уже готовый продукт требуется конвертить — тут согласен, тяжело. Особенно тяжело когда нагородят тяжело портируемого кода, всяких spring, tapestry, linq опять же
Здравствуйте, снежок, Вы писали: С>Но если уже готовый продукт требуется конвертить — тут согласен, тяжело. Особенно тяжело когда нагородят тяжело портируемого кода, всяких spring, tapestry, linq опять же
Вполне достаточно наколбасить тяжело портируемый код на диалекте SQL соответствующего вендора. Как переносить XП между Firebird/MSSQL/Oracle? Только полным переписыванием, а зачастую еще и надо синтаксис вызова поменять и т.п.
Вот тут как раз по идее рулят системы, которые не зависят от тяжеловесных хранимок. Какой-нибудь генератор SQL по концептуальной модели переключается на другого провайдера — и поехали. Например, этим генератором может быть линк. Сейчас он заточен исключительно под MS. Но, поскольку система открытая, никто не запретит тебе дописать back-end для оракл и воспользоваться соответствующими преимуществами.
На всякий случай уточню: это в основном теоретические рассуждения. Практику надо смотреть по практике. Пока рано говорить о том, удастся ли улучшить кросс-DB переносимость за счет линка. По сравнению, естественно, с голым ADO.NET — потому, что всякие гибернейты и геномы уже и так предлагают аналогичную переносимость; разве что построена она на text-only *QL запросах, которые тяжело отлаживать и поддерживать из-за отсутствия compile-time проверок.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, снежок, Вы писали:
С>Правильно, только вот ваш хваленный linq так и подталкивает вновь все размазывать по слоям,
Никуда он не подталкивает, своя-то голова есть?
С>Хором тебе уже готовы кричать, что реляционный он на сервер приходит, а в .net-коде выглядит как подобие объектного, который не каждый сейчас способен граммотно написать.
Что-то слабоват хор.. Именно в .Net коде нет никакого подобия объектного.
С>Да, не спроста, потому что ms, потому что встроили в свой продукт, потому что маркетологи покричали, блогеры попиарили.
Ага, и один ты, такой умный, всех раскусил..
С>Но для работы с БД... дайте нормальный родной маппер на хп
linq тебе его вполне заменит.
С>А так я и до этого в инете мог наковырять с десяток ORM(или назовите как хотите) выполняющих такую же лабуду.
Не мог
С>Помнится предрекали светлое будущее MDA, еще много чего помнится...
Ну, мы-то не о будущем говорим, а о настоящем. В настоящее же время 90% автогенеренного линком SQL работает good enough.
С>Т.е. не будем заморачиваться,
Не то чтобы совсем, заморачиваться будем только в тех случаях, где это оправдано.
C> просто нагенерим везде внешних соединений, даже если хватает или должо быть внутреннее и все ок? Так да?
Если тебя это так заботит, тебе ничто не мешает по прежнему все писать в хранимках.
IB>Ага, и один ты, такой умный, всех раскусил..
А ты внимательно ветку почитай, и поймешь что не я один.
На форум msdn-овский зайди по этому детищу, там почитай вопросы и обсуждения.
С>>Но для работы с БД... дайте нормальный родной маппер на хп IB>linq тебе его вполне заменит.
Да не может он мне его заменить, сколько раз повторять, потому как SingleTableInheritance support only и вообще для data-ориентированных систем.
С этого, собственно, вся ветка и началась!
С>>А так я и до этого в инете мог наковырять с десяток ORM(или назовите как хотите) выполняющих такую же лабуду. IB>Не мог
Я не пойму, мы флудить теперь что ли будем "да-нет-нет-да"? http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet
IB>В настоящее же время 90% автогенеренного линком SQL работает good enough.
Про этот good enough тоже уже неоднократно...
IB>Если тебя это так заботит, тебе ничто не мешает по прежнему все писать в хранимках.
Заботит, поэтому и продолжаю писать в них, а ты, видимо, судя по огню в глазах, кинулся уже все переписывать?
Здравствуйте, снежок, Вы писали:
С>А ты внимательно ветку почитай, и поймешь что не я один.
Да, мух тоже много..
С>Да не может он мне его заменить, Хозяин — барин, не нравится — не ешь.
С> сколько раз повторять, потому как SingleTableInheritance support only и вообще для data-ориентированных систем.
Ну это же как раз ровно то что нужно. В чем проблема-то? (Я, честно говоря, не очень понимаю, назафига вообще как-то саппортить эту самую inheritance)
Никто же не призывает его использовать там где не надо, тебе же уже писали, что границы применимости довольно очевидны.
С>С этого, собственно, вся ветка и началась!
Ну да. Ты начал плакаться что "Меня не устраивает!" и нарвался на совершенно закономерное "А чего ты хотел?".
С>Я не пойму, мы флудить теперь что ли будем "да-нет-нет-да"?
Назвался — полезай.
С>http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet
И какой из них встроен в язык на уровне comprehensions? Не говоря уже о том, что похожей идеологией обладает только iBATIS (отчасти), да еще BLT, которого в этом списке нет.
С>Про этот good enough тоже уже неоднократно...
Афигительный аргумент. Недовольные на ровном месте всегда найдутся, за примерами далеко ходить не надо... =)
С>Заботит, поэтому и продолжаю писать в них,
Ну и в чем тогда проблема? Линк вполне себе работает с хранимками.
С> а ты, видимо, судя по огню в глазах, кинулся уже все переписывать?
Да у меня и так все работает, чего переписывать-то? =)
С>>http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet IB>И какой из них встроен в язык на уровне comprehensions? Не говоря уже о том, что похожей идеологией обладает только iBATIS (отчасти), да еще BLT, которого в этом списке нет.
Речь вообще то шла о генерации sql-кода, зачем выдергивать что то из контекста моих слов и сводить в другое русло?
А если говорить о "встроен в язык" и схожей идеологии:
В каком году вышло первое издание GoF? В каком году вообще выл впервые описан Criteria-pattern?
То что реализацию сriteria-pattern-а встроили в синтаксис языка? В этом что ли великое изобретение и заслуга?
Ну да, синтаксис более удобный, не спорю.
Просто глупо бы было если этого не сделали, т.к. тогда уж точно получилось бы то, чего уже навалом.
По понятным причинам кроме ms никто этого сделать не мог.
А кроме списка приведенного по ссылке, еще с десяток orm дополнительно наковырять можно, которые формируют запросы через criteria-паттерн (впротивоположность непроверяемым на этапе компиляции XX-QL запросам): devexpress XPO, EntitySpace, base4.net (который, кстати, якобы очень центися ms)...
IB>Афигительный аргумент. Недовольные на ровном месте всегда найдутся, за примерами далеко ходить не надо... =)
Запрос, выполняющийся в два раза медленнее из-за использования внешнего соединения вместо внутреннего, это не аргумент? Сомнительные вложенные подзапросы — тоже? Офигенно!
Нормальный t-sql разработчик может написать один и тот же запрос десятью способами, и в разных ситуациях, в зависимости от характера, объема данных оптимальный вариант может оказаться различным.
С этим ты тоже не согласен? Разве можно сказать что абсолютно всегда существует единственно правильный и оптимальный запрос? Всегда ли оптимизатор находит тот самый оптимальный план? А что делать с ora, в котором пошли по противоположному пути (не тратят особо много усилий на создание "умного" оптимизатора) и чаще используется тонкая настройка плана?
Здравствуйте, снежок, Вы писали:
С>Речь вообще то шла о генерации sql-кода, зачем выдергивать что то из контекста моих слов и сводить в другое русло?
Речь шла об ORM инструменте со схожими характеристиками.
С>В каком году вышло первое издание GoF? В каком году вообще выл впервые описан Criteria-pattern?
Criteria-pattern — это не идеология. Идеология — это data-driven поход. Весь зоопарк ORM, как один, до недавнего времени плясали не от данных, а от объектов, что и являлось основным идеологическим косяком подобного рода инструментов.
С>То что реализацию сriteria-pattern-а встроили в синтаксис языка? В этом что ли великое изобретение и заслуга?
И в этом тоже.
С>Просто глупо бы было если этого не сделали, т.к. тогда уж точно получилось бы то, чего уже навалом.
То есть они таки сделали что-то особенное? Отлично, ЧТД.
С>По понятным причинам кроме ms никто этого сделать не мог.
А что мешало?
С>Запрос, выполняющийся в два раза медленнее из-за использования внешнего соединения вместо внутреннего, это не аргумент?
Кто эти "два раза" мерял, в каких условиях и на каких данных? Ты мне оба запроса покажи, план и набор данных, тогда и поговорим. Да, и эти "два раза", должны меряться не микросекундами.
С> Сомнительные вложенные подзапросы — тоже?
Они не сомнительные, они нужные.
С>Нормальный t-sql разработчик может написать один и тот же запрос десятью способами, и в разных ситуациях, в зависимости от характера, объема данных оптимальный вариант может оказаться различным.
Хорошо, что ты это понимаешь..
С>С этим ты тоже не согласен? Разве можно сказать что абсолютно всегда существует единственно правильный и оптимальный запрос? Всегда ли оптимизатор находит тот самый оптимальный план?
Ты это к чему?
С> А что делать с ora, в котором пошли по противоположному пути (не тратят особо много усилий на создание "умного" оптимизатора) и чаще используется тонкая настройка плана?
То что у оракла оптимизатор косячный — исключительно их проблемы, и даже они не очень рекомендуют пинать запрос хинтами, хотя в этом случае возможностей у оракла больше. Причины вообщем понятны, тот план который сегодня оптимальнейшим образом вылизан хинтами, после некоторого времени работы будет сливать в разы сгенеренному оптимизатором, переписывать же каждый раз руками запрос при изменении характера данных — бредовая затея. Учитесь доверять оптимизатору и правильно с ним обращаться.
Добрый вечер, ночь, утро, день, вечер, ...!
Попробую и я высказаться: что касается LINQ to SQL, это конечно очень удобно в коде обращаться к данным в БД. Но на мой взгляд это размазывает DAL по всем уровням, поскольку есть большой соблазн в UI, например, не парится и не обращаться к DAL, а написать код в 3 строчки, тем более что при использовании LINQ to SQL в проекте DAL может вообще не понадобится.
Лично для меня, возможно, это стало следствем моей тупости, но контроль за соединением с БД стал сущим адом, не только за соединением, но и за измененениями которые код должен внести в БД. Из-за размазывания этого DAL, никак не могу найти удобный и быстрый подход к работе с контекстом соединения (может Вы подскажите), увы сам LINQ с этим справляется не очень и приводит к трудно уловимым ошибкам (например, вдруг у контекста соединения пропадает ConnectionString, точнее становится пустой, или был доступ к связанной таблице через совойство, а потом вдруг пропал, причём с соединенем всё в норме, самое ужастное что ошибки все трудно уловимые, потому что DAL уже не принадлежит Вам, ирония судьбы )
Но и несколько слов о LINQ:
— низкая скорость работы: здесь ;
— бывают утечки памяти.
Поймите правильно, я не противник LINQ, я его использую уже давно и в серьёз, но столкнулся с рядом проблем, надеюсь Вы мне поможете их разрешить.
Всех благ!
Здравствуйте, Time, Вы писали:
T>- низкая скорость работы: здесь ;
2008 RC1
— такой студии вообще в природе не существовало. Была RC0, но это большой большой секрет. Ну и считать миллисекунды на миллион итераций при обращении к БД ...
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, снежок, Вы писали:
С>Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером.
Зачем мне "тонко оптимизированный код" в 99% случаев?
Здравствуйте, Aen Sidhe, Вы писали:
AS>Зачем мне "тонко оптимизированный код" в 99% случаев?
Ты не переживай. Мы это всё уже проходили. Я уже насмотрелся на распальцованных пацанов, которые критиковали, к примеру, оптимизатор MS VC 7.0. Типа — во тупая машина, нагенерила всякой ботвы для банального поиска инта в массиве. Щас реальный пацан покажет, как надо искать инт в массиве... И пацан продувает компилеру со счетом 1:1.4.
Теперь, значит, настала эпоха умельцев SQL. Этакий снежок придет и заявит типа "да ну, линк лажа, какой-то ботвы нагенерил, ща я вот с хинтами тут SQL набубеню и покажу, как надо искать инт в массиве".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
iT>Заодно прикинь стоимость соединения таблиц, если, скажем, у тебя в иерархии пару миллионов записей, а отличающихся в потомках свойств — раз два и обчелся.
А вот и не подерётесь. Все упомянутые архитектуры имеют право на жизнь при определённом характере данных и задач.
Да OLAP обычно основан на таблице фактов, но потому это и специализированное хранилище, что подходит не для всех бизнес-задач. Не говоря уже о денормализации с копированием атрибутов.
? Индусы что ли замучали? 
Мы уже победили, просто это еще не так заметно...
. Странно, что не реализованно внутреннего кеширования для идентичных LINQ выражений — поскольку каждый раз выпольняется по сути идентичная работа. Компилируемые запросы конечно помогают, но они возможны не для всех типов выражений.
