Здравствуйте, VladD2, Вы писали:
VD>Взять хотя бы утверждение "SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя". VD>1. В РСБУД и в SQL вообще нет объектов. Стало быть разговор о их возврате — это ээ... ну, сам придумай как это по мягче назвать, в общем.
Объектов нет, есть записи (record) — строки таблиц имеющие определённые поля (field). По видимой форме массив структур Си и таблица SQL принципиально не отличаются. Однако, SQL позволяет делать довольно нехорошую, с точки зрения ORM, вешь — возвращать часть записи. Да и целая запись не подарок. Даже установив конкретный формат возвращаемых запросом данных, однозначно определить тип C# на который надо произвести отображение нельзя.
VD>2. Утверждение о нетипизированности запросов стоило бы обосновать. Оно явно не верно, но без твоего обоснования я должен тратить свои силы на обоснование очевидного факта.
Я ответил выше — результаты запроса никак не могут быть связаны с типом C#, попросту не хватает информации.
VD>3. Запрос, в РСУБД, всегда возвращает список записей (они не даром так называются, запись это кортеж с именованными полями). Единичное (скалярное) значение не более чем частный случай — список состоящий из одной записи которая в свою очередь состоит из одного элемента (поля). VD>Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема.
Проблема и ещё какая.
VD>Теперь о причинах по которым тебе тяжело будет объяснить почему ты не прав. VD>Дело в том, что ты исходишь из узкого и не верного трактования действительности. Ты смотришь на доступ к данным через призму ООП-теории. Этот взгляд не может привести к пониманию обсуждаемого в данной теме. Отсюда все разговоры о выборе объектов из базы. О каких то там связях частей объектов и т.п. VD>Так что первое что нужно понять для понимания этой темы — в БД нет объектов. И мы просто предлагаем вместо работы с объектами в БД, работать с данными вынимаемыми из БД и размещаемыми структурах удобных для обработки в прикладном языке программирования.
Влад, я искрене рад, что у тебя достаточно богатая фантазия и ты придумал объективную реальность.
Здравствуйте, Tom, Вы писали:
Tom>Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.
Этот код не надо рефакторить. Его нужно переписывать.
Tom>Сейчас мы этого не сможем сделать но в следующей версии рефакторинг базы конечно надо будет делать. Tom>Я просто хочу понять основные принципы. Или ты опять о тотальном переносе всего в C#?
Что значит тотальном? В моих приложениях императивная логика на TSQL отсутствует или устраняется, если есть в старом коде, при первой же возможности. SQL (в моём случае Sybase) выполняет только одиночные запросы без всяких IF и WHILE в SQL. Бывают, конечно, исключения, как правило это ситуации, когда необходимо нагенерировать большое количество записей по данным в БД и вставить эти записи обратно в БД. Если генерацию делать на клиенте, то вставка в базу происходит долго, гораздо эффективнее это делать скриптом. Но и здесь пока мне удавалось избегать IF и WHILE. Если же случай совсем невменяемый, то я предпочитаю сгенерировать SQL под конкретную задачу на клиенте и затем выполнить его. Как показывает практика поддержка такого решения гораздо проще, чем поддержка императивщины на TSQL.
Но это всё случаи из разряда два процента от всей работы с SQL и подход к ним отдельный. Хотя подумать над тем как генерировать на linq подобные скрипты всё же стоит.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
IT>>Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать? Tom>О коде который ты сейчас пишешь. Провайдер.
Даже не знаю, никогда не задавался этим вопросом. Сколько получится, столько и будет. Ну может 7-10 тысяч строк наберётся, смотря как считать. В BLToolkit уже многие вещи реализованы, такие как маппинг, БД провайдеры, SqlBuilder тоже имеет отдельную ценность и непонятно нужно его включать в рассмотрение или нет. Сам парсер будет 1,5-2 тыщи строк, всякие полезняшки там. Больше всего кода это всевозможные методы обхода Expression Tree. Код тупой, но никуда не денешься. На Немерле как раз такие вещи было бы делать на порядок проще.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0? VD>Я слышал обратное. В прочем я слышал это о C#.
Я одним глазом глянул. Если я правильно понял, речь идёт о структурной идентичности интерфейсов. Т.е. помечается интерфейс специальными атрибутами и два интерфейса в разных сборках считаются одинаковыми. Нужно для интеропа, чтобы не таскать с собой интеропные офисные сборки по 10 мег, а встраивать в свои сборки только используемые интерфейсы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, SleepyDrago, Вы писали:
A>>>Нет. Редактор редактирует только модель. Генератор существует совсем отдельно ... SD>>именно это и было сделано. Редактор ооп модели. Вам же в теме показывали листинги "сложных запросов" Чем вы предлагаете их заменить?
A>Я задачу "генерировать всё" вообще никогда перед собой не ставил. Нет и не может быть удобного универсального генератора для всего. Я ставил задачу сгенерировать 90%, и позволить остальные 10% писать руками
В общем проясним сразу. Сущности ООП модели — 10% клиентского кода. Они не понятны и неприемлемы ни для dba ни для спецов предметной области. На удивленные возгласы мол если спецы предметной области в софт конторе не знают ооп то могут искать другую работу, ответ очень простой — спецы бесценны, а ооп нет. Это означает что от модели предметной области до решения покрывающего 90% кода тесно связанного с обработкой данных — как до пекина раком. Так что согласны вы с Tom или нет предложить вам ему нечего тк у него основная масса логики в базе. Вариант "просто переписать все на С#/Linq" любым разумным менеджером будет послан, разве что систему будут утилизировать и будет финансирование "с чистого листа".
зы сорри за прямоту — не со зла, просто это уже съеденные собаки
Здравствуйте, SleepyDrago, Вы писали:
SD>В общем проясним сразу. Сущности ООП модели — 10% клиентского кода. Они не понятны и неприемлемы ни для dba ни для спецов предметной области. На удивленные возгласы мол если спецы предметной области в софт конторе не знают ооп то могут искать другую работу, ответ очень простой — спецы бесценны, а ооп нет. Это означает что от модели предметной области до решения покрывающего 90% кода тесно связанного с обработкой данных — как до пекина раком.
Стоп, а разве я описываю объектную модель? Вовсе нет. Я описываю сущности. Как может специалист предметной области не разбираться в сущностях?
SD>Так что согласны вы с Tom или нет предложить вам ему нечего тк у него основная масса логики в базе. Вариант "просто переписать все на С#/Linq" любым разумным менеджером будет послан, разве что систему будут утилизировать и будет финансирование "с чистого листа".
Систему где бизнес логика в SQL надо переписывать вне зависимости от используемых технологий.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, adontz, Вы писали:
A>>>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов. G>>Вы описываете то что относиться к бизнес-логике.
A>Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.
"получить конкретный элемент по идентификатору" относится к бизнес-логике, а не к доступу к данным. Абстракции над БД должно быть абсолютно пофиг что ты хочешь сделать с возвращаемыми данными.
DAL должен обеспечивать возможность получить последовательность элементов, соотвествующих некоторым условиями фильтрации\проекции\группировки.
A>>>Я уже выше отписался, почему считаю этот вопрос актуальным. G>>Тем не менее этот вопрос никак не связан со способом работы с данными.
A>Методы работы с БД должны учитывать возможность изменения схемы. Использовать другие методы, значит отрицать возможность рефакторинга БД и, тем самым, существенно его удорожать.
Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД.
Здравствуйте, gandjustas, Вы писали:
G>"получить конкретный элемент по идентификатору" относится к бизнес-логике, а не к доступу к данным.
С какой это стати? Осмысливания содержимого элемента и обработки тут нет. Никакая это не бизнес-логика.
G>Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД.
IQueryable не надо, надо методике доступа к БД, которая включает в себя Linq.
Здравствуйте, adontz, Вы писали:
A>Объектов нет, есть записи (record) — строки таблиц имеющие определённые поля (field). По видимой форме массив структур Си и таблица SQL принципиально не отличаются. Однако, SQL позволяет делать довольно нехорошую, с точки зрения ORM, вешь — возвращать часть записи. Да и целая запись не подарок. Даже установив конкретный формат возвращаемых запросом данных, однозначно определить тип C# на который надо произвести отображение нельзя.
Как все запущено!
Рама, забудь свои знания С. Они тут тебе не помогут.
"Запись", о которой я говорил — это тип данных, а не понятие из РСУБД (где, впрочем они рассматриваются так же, прост ты не привык). Запись есть набор разнотипных именованных значений. Скажем в C# 3.0 ей аналогичны анонимные типы. Не полностью аналогичны, правда... с ограничениями... но все же для возврата значений из БД анонимных типов более чем достаточно.
Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.
А ты не можешь понять это потому, что смотришь через призму объектов и ООП.
Вот тебе и мерещатся объекты получаемые соединением по FK и другая ерунда.
A>Я ответил выше — результаты запроса никак не могут быть связаны с типом C#, попросту не хватает информации.
Очень смешно!
VD>>3. Запрос, в РСУБД, всегда возвращает список записей (они не даром так называются, запись это кортеж с именованными полями). Единичное (скалярное) значение не более чем частный случай — список состоящий из одной записи которая в свою очередь состоит из одного элемента (поля). VD>>Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема.
A>Проблема и ещё какая.
С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Tom, Вы писали:
Tom>>Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить. IT>Этот код не надо рефакторить. Его нужно переписывать.
Ну почему же, приведенный кусок го... TSQLя можно и отрефакторить.
1)Эта нереальная процедура выполняется фактически 3 разных действия, селектор по параметру @Mode, её стоит разбить на 3 функции
2)Все хранимки с одним output-параметром заменить на функции, сразу же можно будет убрать обработку с помощью курсоров.
3)Врмененные таблицы позаменять на табличные переменные
4)Для получения значений #tz можно использовать table-valued function
Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.
Если ко времени окончания рефакторинга появится DML для Linq, то можно поотказываться от фунцкий и динамически строить запросы с помощью Linq, а потом передавать нужные значения в INSERT и UPDATE.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>"получить конкретный элемент по идентификатору" относится к бизнес-логике, а не к доступу к данным. A>С какой это стати? Осмысливания содержимого элемента и обработки тут нет. Никакая это не бизнес-логика.
Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.
G>>Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД. A>IQueryable не надо, надо методике доступа к БД, которая включает в себя Linq.
Linq = IEnumerable\IQueryable + extension methods + anonimous types + object initializers + sql-подобный синтаксис.
Для полноценной работы с данными не хватает только DML — insert\update\delete.
Зачем этому всему учитывать возможность рефакторинга БД ?
Или всетаки имеются ввиду конкретные реализации Linq-провайдеров: схемы маппинга, кеширования и прочего?
Так они вообще-то мало зависят от самого Linq.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, VladD2, Вы писали:
VD>>То и значит. Нет полей. Нет "структуры". D>Тоесть для интерфейса понятие структурной эквивалентности не применимо?
Естественно. У них интерфейсная эквивалентность.
Интерфейсно эквивалентными могут быть два разных типа.
Просто теперь интерфейсная эквивалентность будет работать и для разных интерфейсов имеющих один гуид, и одинаковую сигнатуру. Сделано это для интеропа и для плагинов.
D>нельзя назвать эквивалентностью интерфейсов?
Можно. Но именно интерфейсов, а не структуры типа.
D>Можно тогда какой нибудь пример применения этой самой структурной эквивалентности?
Вот если бы можно было бы написать что-то воде:
struct A { int a; }
struct B { int a; }
A a = new A();
B b = a;
То была бы структурная эквивалентность.
Причем для именованных типов это особо и не нужно. А вот для анонимных нужно и очень.
Тогда можно было бы просто объявить два разных анонимных типа в разных сборках и использовать их не думая где был объявлен какой переменной.
VD>>Крут ты! Я вот не знаю как такое сделать, да еще чтобы при этом не пересечься с гуидами сгенерированными другими средствами. D>Ну а чего, для IValue берем строку вида "int,Value" и генерим по ней Guid, дешево и сердито.
Здорово. Только вот в Guid 128 бит. Что будем делать если встретятся описания которые больше 128 бит в запакованном виде?
И что будем делать если один из гуидов пересечется с тем, что был сгенерирован как обычный гуид?
В общем, это не решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
IT>Но это всё случаи из разряда два процента от всей работы с SQL и подход к ним отдельный. Хотя подумать над тем как генерировать на linq подобные скрипты всё же стоит.
Хорошо, пункт один — императивная логика. Мне правда пока не совсем понятно почему в TSQL её лучше не использовать, но возможно позже понимание придёт. Что ещё можно сделать что бы улучшить этот код. Влад например предлагал устранить временные таблицы и курсоры. насчёт курсоров конечно понятно что лучше без них. Насчёт временных таблиц я пока не уверен что тотальное их устранение улучшит понимание кода.
G>3)Врмененные таблицы позаменять на табличные переменные
А чем это улучшит код?
G>4)Для получения значений #tz можно использовать table-valued function
Не понял четно говоря.
G>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.
Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?
G>Если ко времени окончания рефакторинга появится DML для Linq, то можно поотказываться от фунцкий и динамически строить запросы с помощью Linq, а потом передавать нужные значения в INSERT и UPDATE.
Здравствуйте, IT, Вы писали:
VD>>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0? VD>>Я слышал обратное. В прочем я слышал это о C#.
IT>Я одним глазом глянул.
Я тоже.
IT>Если я правильно понял, речь идёт о структурной идентичности интерфейсов. Т.е. помечается интерфейс специальными атрибутами и два интерфейса в разных сборках считаются одинаковыми. Нужно для интеропа, чтобы не таскать с собой интеропные офисные сборки по 10 мег, а встраивать в свои сборки только используемые интерфейсы.
У интерфейсов нет стуктуры. Они потому так и называются "интерфейс". Толку с интерфейсов в данном случае — нет. Мы же не об интеропе говорим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Рама, забудь свои знания С. Они тут тебе не помогут. VD>"Запись", о которой я говорил — это тип данных, а не понятие из РСУБД (где, впрочем они рассматриваются так же, прост ты не привык). Запись есть набор разнотипных именованных значений. Скажем в C# 3.0 ей аналогичны анонимные типы. Не полностью аналогичны, правда... с ограничениями... но все же для возврата значений из БД анонимных типов более чем достаточно.
Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.
VD>Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.
Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.
A>>Я ответил выше — результаты запроса никак не могут быть связаны с типом C#, попросту не хватает информации. VD>Очень смешно!
Да нет, весьма грустно.
VD>>>Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема.
Проблема, по той простой причине, что одному типу C# может соответствовать не одна таблица БД, и напротив одна таблица может содержать данные для разных типов C#. Если ты не придумал искуственный интеллект, то проблема не решена.
VD>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.
Здравствуйте, Tom, Вы писали:
G>>3)Врмененные таблицы позаменять на табличные переменные Tom>А чем это улучшит код?
Это позволит ими манипулировать как значениями. Возвращать из функций, например. А это уже позволит произвести декомпозицию самой функции на ряд более мелких чей смысл будет понятен после беглого просмотра (а то и просто почитав имя).
G>>4)Для получения значений #tz можно использовать table-valued function Tom>Не понял четно говоря.
Использовать функции которые возвращают табличные значения. Это аналогично использованию параметризованных запросов или подзапросов.
G>>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код. Tom>Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?
Ифы в TSQL-е императивный. В итоге вся процедура превращается в смесь запросов и императива. Ее надо или забить на несколько процедур, или переписать без ветвления (так чтобы были одни запросы).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
IT>>Но это всё случаи из разряда два процента от всей работы с SQL и подход к ним отдельный. Хотя подумать над тем как генерировать на linq подобные скрипты всё же стоит. Tom>Хорошо, пункт один — императивная логика. Мне правда пока не совсем понятно почему в TSQL её лучше не использовать, но возможно позже понимание придёт. Что ещё можно сделать что бы улучшить этот код. Влад например предлагал устранить временные таблицы и курсоры. насчёт курсоров конечно понятно что лучше без них. Насчёт временных таблиц я пока не уверен что тотальное их устранение улучшит понимание кода.
Еще (по уму) нужно устранить update-ы delete-ы во временных таблицах.
Если логика в коде процедуры будет фильтрующей, то ее будет значительно проще поддерживать и развивать. При этом тебе ну будут нужны уже все управляющие конструкции. Будет только входные данные, преобразование и выходные данные, которые и надо вставлять в таблицы.
Увидишь, что когда перепишешь так код, то упростится не только его отладка, но и понимание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
G>>3)Врмененные таблицы позаменять на табличные переменные Tom>А чем это улучшит код?
Никак, это типа best-practicies.
Хотя в сочетании с table parameters (MS SQL 2008) можно получить функционально чистое решение даже на TSQL.
G>>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код. Tom>Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?
Чтобы уменьшить сложность TSQL кода. Править C# гораздо проще, чем TSQL.
Кроме того к разными веткам IF в SQL могут приводить совершенно разные сценарии в программе.
Если нам не помогут, то мы тоже никого не пощадим.
