Здравствуйте, Tom, Вы писали:

IT>>Компилятор то тут при чём?
Tom>Мне кажется без изменения компилятора и синтаксиса языка полноценную работу с данными в него не впихнуть.

Если ты имеешь ввиду расширение синтаксиса для поддержки Linq, то компилятор всего лишь преобразовывает этот синтаксис в последовательность вызовов методов с определённой сигнатурой. А самому linq2sql всё равно каким из следующих двух способов ты выразишь свой запрос:

var q1 = from p in db.Person where p.ID == 1 select p;
var q2 = db.Person.Where(p => p.ID == 1).Select(p => p);

Если написать соответствующие методы Update/Insert/Delete и обучить linq провайдера их понимать, то проблема решена. Без участия компилятора.

Здравствуйте, VladD2, Вы писали:

VD>Вот только в 4-ом дотнете, где будет новый рантайм, все равно ничего для поддержки структурной идентичности сделано не будет.
И еще раз http://channel9.msdn.com/pdc2008/TL02/

Здравствуйте, IT, Вы писали:

IT>Если написать соответствующие методы Update/Insert/Delete и обучить linq провайдера их понимать, то проблема решена. Без участия компилятора.

А в каком примерно синтаксисе это будет?

Здравствуйте, vdimas, Вы писали:

IT>>Если написать соответствующие методы Update/Insert/Delete и обучить linq провайдера их понимать, то проблема решена. Без участия компилятора.

V>А в каком примерно синтаксисе это будет?

Delete просто Delete()
Insert я бы сделал как .Insert(p => new Person { ID = p.ID, ...})
Update скорее всего так же как и Insert, но можно рассмотреть и другие варианты, семантически более близкие к соответствующей операции.

Здравствуйте, VladD2, Вы писали:


VD>Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, gandjustas, Вы писали:

G>>Полу-именнованный кортеж чтоли? Такое хоть где-то работает?

VD>Да. Во многих ФЯ. В ОКамле, например. Называется запись (record).
VD>Но в ФЯ типы кортежей совместимы по структуре. Это называется структурной идентичностью.
VD>Если объявить две записи с одним набором полей (и типов у каждого поля), то их объекты будут иметь один тип и их можно будет использовать друг вместо друга. Так же их можно будет сравнивать и копировать.

VD>Но такая фича не поддерживается в дотнете. По этому даже ФЯ реализованные на дотнете не поддерживают записей (по крайней мере в полной мере).

Я в курсе что такое записи, я не понял как будет работать в такой записи:

{string, int} t = new {Name="", 123}

Как компилятор будет понимать {string, int}? И как будет выводить имя второго поля в записи new {Name="", 123}?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, VladD2, Вы писали:


VD>>Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.

V>От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего. Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.
Да ну? Вообще-то компилятор запроса ругается при таком раскладе.
SQL вообще говоря типизированный, только проверка типа осуществляется гораздо позже, чем хотелось бы программисту.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Tom, Вы писали:

Tom>>Ну тогда тебе в ORM лагерь.

IT>Это смотря какой ORM? ORM'ы бывают разные. Бывают heavy ORM, бывают lightweight ORM. BLToolkit относится ко второй категории.

IT>Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.

Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.
Сейчас мы этого не сможем сделать но в следующей версии рефакторинг базы конечно надо будет делать.
Я просто хочу понять основные принципы. Или ты опять о тотальном переносе всего в C#?

IT>Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?
О коде который ты сейчас пишешь. Провайдер.

Здравствуйте, Tom, Вы писали:

Tom>Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.
Tom>Сейчас мы этого не сможем сделать но в следующей версии рефакторинг базы конечно надо будет делать.
Tom>Я просто хочу понять основные принципы. Или ты опять о тотальном переносе всего в C#?

Переписывать за тебя это вряд ли кто станет. Но советы можно дать.
1. Избавиться ото всех курсоров.
2. Избавиться ото всех временных таблиц.
3. Разделить логику выборки и логику вставки/обновления данных, так чтобы четко было видно, что за информация вычисляется и как она обновляется в таблицах.

Пункты 1 и 2 можно сделать если использовать табличные переменные и/или хранимые функции.

Собственно как только вы это сделаете, то вопрос перобразования этого дела в тот же linq+ будет вопросом чисто механическим.

Здравствуйте, Tom, Вы писали:

IT>>Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?
Tom>О коде который ты сейчас пишешь. Провайдер.

Ну, дык, этот же код он будет поддерживать. Тебе то что?

Тут важен не объем кода, а его качество (читаемость, структурированость).

Здравствуйте, Tom, Вы писали:

VD>>Скорее record которого нет ни в Немерле, ни в Шарпе.
Tom>А в чём разница между tuple и record?

В том, что поля у последнего именованные.
Проблема в том, что tuple можно разместить в библиотеке и использовать для всех экзепляров один и тот же тип (generic, естественно). А вот record не может быть помещен в библиотеку так как имена полей различаются.

В принципе можно было бы попытаться эмулировать record через tuple, но это довольно сложно. Ведь для этого пришлось бы везде протаскивать расширенную информацию о типах. Придется вводить в компилятор дополнительный тип и кодировать его черт знает каким образом в сборках. В общем, геморрой. И это при том, что tuple (кортежи) решают проблему не намного хуже.

А record нужно было бы ввести на уровне CLR. Тогда его поддержка в компиляторе была бы элементарным делом.

Здравствуйте, dotneter, Вы писали:

VD>>Вот только в 4-ом дотнете, где будет новый рантайм, все равно ничего для поддержки структурной идентичности сделано не будет.
D>И еще раз http://channel9.msdn.com/pdc2008/TL02/

Что значит "еще раз"? У меня нет времени смотреть мультфильмы.

Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?
Я слышал обратное. В прочем я слышал это о C#.

Здравствуйте, vdimas, Вы писали:

V>От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего.

Типизированность (Что за слова дурацкое? Лучше сказать "Строгая статическая типизация") она никакого отношения к ООП не имеет. Возьми Руби, Смолток и иже с ними. Там типизация слабая и динамическая. При этом поддержка ООП на высшем уровне.

Если уж нужна мощьная типизация в БД, то стоит обратить внимание на системы типов МЛ-подобных языков и на Хаскель. Вот только последний склеить с современными ООЯ будет еще сложнее.
Хотя как раз система типов МЛ ложится на БД просто замечательно.

Так что если и говорить о новых видах БД, то скорее нужно говорить о функциональных БД — ФБД, а не ООБД.

V>Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.

Это вопрос строгости типизации. Есть СУБД которые не позволяют этого сделать. То что MS SQL имеет довольно слабую (и откровенно говоря дряхлую и кривую) систему типов — это проблемы Microsoft и от части Sybase, а не РСУБД.

Здравствуйте, gandjustas, Вы писали:

G>Я в курсе что такое записи, я не понял как будет работать в такой записи:

G>

G>{string, int} t = new {Name="", 123}
G>

Эта запись — фантазия человека. Конечно разумнее было бы использовать более классическую запись вроде:

Name : string * ID : int

G>Как компилятор будет понимать {string, int}? И как будет выводить имя второго поля в записи new {Name="", 123}?

Никак. Это, скорее всего, просто ошибка автора того сообщения. Конечно имя должно задаваться явно. Или при описании типа, или внутри выражения. Если уж есть описание типа, то конечно в нем.

Здравствуйте, Tom, Вы писали:

Почитал дискуссию, не согласен со всеми
Суть задачи в том, чтобы сгенерировать DAL и немножечко бизнес логики (ну сколько получится). DAL в свою очередь, грубо говоря, состоит из SQL и C#. При этом почему-то ошибочно предполагается что C# или SQL могут хранить всю информацию, необходимую для генерации части на другом языке или даже могут это делать удобно. Враки это всё. Хуже того, сгенерировать DAL это пол-беды, надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.

C# генерировать из SQL нельзя по той простой причине, что SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя. К тому же сам SQL, как способ описания сущностей, неприемлем. Один объект может храниться в нескольких таблицах, связи между объектами (FK) устанавливаются не очень удобно и не несут однозначного смысла.

SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.

DAL не просто можно, его обязательно нужно генерировать. Но не C# из SQL или SQL из C#. И то и другое надо генерировать из третьего, более приспособленного для хранения условий задачи, источника.м

VD>Ну, дык, этот же код он будет поддерживать. Тебе то что?
Если вдруг мы решим его использовать то ждать пока кто то пофиксит там баг который для нас является критическим конечно мы не будем.
ну и просто что бы оценить сложность решения хотелось бы понять его обьём.

VD>Тут важен не объем кода, а его качество (читаемость, структурированость).
Кто же спорит

VD>Никак. Это, скорее всего, просто ошибка автора того сообщения.
Моя описка

A>Почитал дискуссию,
Ну ты монстр

A>A>не согласен со всеми


A>Суть задачи в том, чтобы сгенерировать DAL и немножечко бизнес логики (ну сколько получится). DAL в свою очередь, грубо говоря, состоит из SQL и C#. При этом почему-то ошибочно предполагается что C# или SQL могут хранить всю информацию, необходимую для генерации части на другом языке или даже могут это делать удобно. Враки это всё. Хуже того, сгенерировать DAL это пол-беды,


A>надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.
Обновление системы и БД это отдельный разговор. В этой ветке его лучше не упоминать.

A>C# генерировать из SQL нельзя по той простой причине, что SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя.
На самом деле мне тоже так показалось. Давай рассмотрим случай когда нам надо вернуть один обьект или несколько. Допустим у нас есть функции ***GetById и ***GetAll. Допустим в первой мы хотим возвращать один обьект а во второй List<Ы> обьектов. Пока всё хорошо. Теперь рассмотрим случай когда в БД для обоих вызовов не нашлось записи. Что возвращать в таком случае? Для первой функции вариантов только два, null или исключение. Для второй больше. null, пустой список, исключение. В варианте null для первой функции у нас добавляется дополнительное действие. После вызова функции — проверка что обьект не null. А следовательно, мы смело можем возвращать всегда список, для обоих функций. Тоесть и из ***GetById и ***GetAll возвращать List<>. С одной стороны это выглядит как то не так, а с другой, если возвращаться один обьект, то всё равно проверку на null надо будет делать а тогда какая разница.

A>К тому же сам SQL, как способ описания сущностей, неприемлем. Один объект может храниться в нескольких таблицах, связи между объектами (FK) устанавливаются не очень удобно и не несут однозначного смысла.
Открою тебе секрет. Понятия сущность в природе не существует. В природе существуют два других — таблица и выборка. В таблицу надо делать вставки и обновления. А выборка может жить собственной жизнью, и набор полей зависит только от логики самой выборки.

A>SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.
Обновление схемы — это отдельный вопрос. Вопрос решаемый разными путями, предлагаю обсуждать не тут.

A>DAL не просто можно, его обязательно нужно генерировать. Но не C# из SQL или SQL из C#. И то и другое надо генерировать из третьего, более приспособленного для хранения условий задачи, источника.м-
Об этом говорил Влад, что и то и то надо генерить по некоторой модели. Но на данный момент есть легаси приложение которое надо переносить на .NET причём эволюционным путём. Переписыть всё с нуля — такой подход невозможен.

Здравствуйте, Tom, Вы писали:

A>>надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.
Tom>Обновление системы и БД это отдельный разговор. В этой ветке его лучше не упоминать.

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

A>>C# генерировать из SQL нельзя по той простой причине, что SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя.
Tom>На самом деле мне тоже так показалось. Давай рассмотрим случай когда нам надо вернуть один обьект или несколько. Допустим у нас есть функции ***GetById и ***GetAll. Допустим в первой мы хотим возвращать один обьект а во второй List<Ы> обьектов. Пока всё хорошо. Теперь рассмотрим случай когда в БД для обоих вызовов не нашлось записи. Что возвращать в таком случае? Для первой функции вариантов только два, null или исключение. Для второй больше. null, пустой список, исключение. В варианте null для первой функции у нас добавляется дополнительное действие. После вызова функции — проверка что обьект не null. А следовательно, мы смело можем возвращать всегда список, для обоих функций. Тоесть и из ***GetById и ***GetAll возвращать List<>. С одной стороны это выглядит как то не так, а с другой, если возвращаться один обьект, то всё равно проверку на null надо будет делать а тогда какая разница.

ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов.

Tom>Открою тебе секрет. Понятия сущность в природе не существует. В природе существуют два других — таблица и выборка. В таблицу надо делать вставки и обновления. А выборка может жить собственной жизнью, и набор полей зависит только от логики самой выборки.

Понятие сущности есть. Есть сущность — клиент. У него есть множество предопределённых свойств хранящихся в таблице Customers и множество добавленных пользователями, хранящихся в таблице CustomerProperties в виде (CustomerID, PropertyName, PropertyValue). Соответственно есть extandable сущность customer. Этого определения вполне достаточно, чтобы сгенерировать схему БД, а так же все операции вставки, обновления и выборки.

A>>SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.
Tom>Обновление схемы — это отдельный вопрос. Вопрос решаемый разными путями, предлагаю обсуждать не тут.

Я уже выше отписался, почему считаю этот вопрос актуальным.

Tom>Об этом говорил Влад, что и то и то надо генерить по некоторой модели. Но на данный момент есть легаси приложение которое надо переносить на .NET причём эволюционным путём. Переписыть всё с нуля — такой подход невозможен.

А кто сказал переписывать с нуля? Можно генерировать так, чтобы получалось то же самое или почти то же самое, что есть сейчас. Внешний генератор тем и хорош, что сам по себе не видим, только результаты.