Сообщение Re[6]: linq2db и Убивец 1С от 25.06.2020 6:53
Изменено 25.06.2020 7:26 Serginio1
Re[6]: linq2db и Убивец 1С
Здравствуйте, Mystic Artifact, Вы писали:
S>> Так например для неопределенных справочников формируется запрос по доступным справочникам. Кстати в C#9 предлагается юнионы (ограничения на типы)
S>>
MA> Название расходится с примером. Это не ограничение на типы — это бред сумасшедшего. Оно просто не нужно. Более того, кому нужно — у тех уже 20 лет как все карты на руках (object, не?). И это довольно широко применяется в .NET все время его существование, но всегда маскируется за типизированными библиотеками. Да, люди экономят байты, там где есть профит. Лучше бы починили Dictionary<TStruct, TKey> где TStruct — 64-битная структура, при этом проседает по скорости раз в 5 по отношению к long.
В TypeScript прекрасно работают и для БД это ограничение на типы без атрибутов можно вводить
S>>В 1С существуют поля неопределенного типа. Это например план счетов и прочее. В таких полях может содержаться тип,ВидСправочника, Ид
S>>https://infostart.ru/public/402038/
MA> Именно с полями неопределенного типа невозможно нормально ничего сделать. Давай их проссумируем — а тут по середине — строка? Это значит, "неверное" значение нужно пропустить или выдать ошибку? Для того, что бы эффективно работать с любыми данными — нужно разобраться с ними, а не скидывать всё в одно болото. Да, это бывает дается не сразу, но в учетке то... не знаю. Ну, ладно. У нас был ещё последний тип по моему вариант, который никогда фактически не использовался. По сути то, нет проблем и динамически структуру БД менять — просто многие преимущества LINQ пропадут. Хотя linq2db останется полезным, т.к. имеет кучу вкусняшек всё равно.
Просто есть тип, по типу и отфильтруем. Это не проблема. А вот linq2db можно под такие задачи и подпелить.
Кстати тот же case https://stackoverflow.com/questions/4244023/select-case-in-linq
S>> Можно создать по такому типу запросы. С ограничением по типу, с выборкой всех типов итд.
S>>Ну и учтиывая патерн матчинг можно и по другому запросы писать и генерировать!
MA> Ничего это не даёт ровным счетом. Есть логическая схема данных. Есть физическая (в БД). Задача — превратить один сформулированный запрос в другой (на SQL). Это вообще задача почти прямого маппинга, тут ни фичи языка, ни LINQ как таковой особой роли не роялят, и решается она достаточно просто. Иногда выглядит кошмарно. Иногда красиво. Последний раз когда я встречал подобную задачу — это было что-то около 150Кб кода на VB.NET. И все только вокруг него ходили и охали и ахали, но ничего кардинального с этим построителем запросов сделать нельзя, а LINQ вообще туда не лезет, потому что запрос полностью динамический, от таблиц, фич клиентов до кол-ва результирующих колонок. На самом деле сделать можно, но тогда разломать прийдется решительно всё. Но при этом LINQ ни в каком виде всё равно не применим. Такова специфика.
MA> Основная сила LINQ открывается в комбинировании уже готовых запросов или подзапросов, особенно построенных динамически. И одного этого на самом деле достаточно. Комбинирование банальных фильтров — это уже хорошо. А он позволяет гораздо больше. Но, оно даже без этого всего — оно хорошо, когда у тебя есть четкая (единая) структура БД. Есть и ситуации когда параметризированные запросы не подходят, — и linq2db тоже имеет ответ на это. Но, этот самый "маппинг" (смысловой) — он же статический. LINQ открывает очень много возможностей, и linq2db — ну, весьма хороший инструмент.
MA> Но, я может не правильно выразился изначально — сам по себе — этот инструмент, каким бы он не был — просто не может быть определяющим.
MA> А в такой универсальной системе — если идти с фиксированной схемой — это имеет одни границы. Они подходят? А если не фиксированной — то применение LINQ вообще ограничится набором фиксированных служебных таблиц, где применение любого linq-провайдера в относительной доли окажется смешным.
MA> PS: Это мое лично мнение, я не навязываю и не претендую на правоту и единство. Просто всему своё место.
Ну я на 1С программировал лет 20. И знаю о чем говорю. Там и SQL даже не вессь стандарт SQL 92 поддерживает. У Linq даже больше возможностей.
Что касается диначмического характера запросов, то как раз Linq удобен для склейки запросов. В отличие от текста. Все типизированно.
S>> Так например для неопределенных справочников формируется запрос по доступным справочникам. Кстати в C#9 предлагается юнионы (ограничения на типы)
S>>
S>>var crazyCollectionFP = new List<int|double|string>{1, 2.3, "bassam"};
S>>MA> Название расходится с примером. Это не ограничение на типы — это бред сумасшедшего. Оно просто не нужно. Более того, кому нужно — у тех уже 20 лет как все карты на руках (object, не?). И это довольно широко применяется в .NET все время его существование, но всегда маскируется за типизированными библиотеками. Да, люди экономят байты, там где есть профит. Лучше бы починили Dictionary<TStruct, TKey> где TStruct — 64-битная структура, при этом проседает по скорости раз в 5 по отношению к long.
В TypeScript прекрасно работают и для БД это ограничение на типы без атрибутов можно вводить
S>>В 1С существуют поля неопределенного типа. Это например план счетов и прочее. В таких полях может содержаться тип,ВидСправочника, Ид
S>>https://infostart.ru/public/402038/
MA> Именно с полями неопределенного типа невозможно нормально ничего сделать. Давай их проссумируем — а тут по середине — строка? Это значит, "неверное" значение нужно пропустить или выдать ошибку? Для того, что бы эффективно работать с любыми данными — нужно разобраться с ними, а не скидывать всё в одно болото. Да, это бывает дается не сразу, но в учетке то... не знаю. Ну, ладно. У нас был ещё последний тип по моему вариант, который никогда фактически не использовался. По сути то, нет проблем и динамически структуру БД менять — просто многие преимущества LINQ пропадут. Хотя linq2db останется полезным, т.к. имеет кучу вкусняшек всё равно.
Просто есть тип, по типу и отфильтруем. Это не проблема. А вот linq2db можно под такие задачи и подпелить.
Кстати тот же case https://stackoverflow.com/questions/4244023/select-case-in-linq
from u in users
let range = (u.Age >= 0 && u.Age < 10 ? "0-25" :
u.Age >= 10 && u.Age < 15 ? "26-40" :
u.Age >= 15 && u.Age < 50 ? "60-100" :
"50+")
group u by range into g
select new { g.Key, Count=g.Count() };S>> Можно создать по такому типу запросы. С ограничением по типу, с выборкой всех типов итд.
S>>Ну и учтиывая патерн матчинг можно и по другому запросы писать и генерировать!
MA> Ничего это не даёт ровным счетом. Есть логическая схема данных. Есть физическая (в БД). Задача — превратить один сформулированный запрос в другой (на SQL). Это вообще задача почти прямого маппинга, тут ни фичи языка, ни LINQ как таковой особой роли не роялят, и решается она достаточно просто. Иногда выглядит кошмарно. Иногда красиво. Последний раз когда я встречал подобную задачу — это было что-то около 150Кб кода на VB.NET. И все только вокруг него ходили и охали и ахали, но ничего кардинального с этим построителем запросов сделать нельзя, а LINQ вообще туда не лезет, потому что запрос полностью динамический, от таблиц, фич клиентов до кол-ва результирующих колонок. На самом деле сделать можно, но тогда разломать прийдется решительно всё. Но при этом LINQ ни в каком виде всё равно не применим. Такова специфика.
MA> Основная сила LINQ открывается в комбинировании уже готовых запросов или подзапросов, особенно построенных динамически. И одного этого на самом деле достаточно. Комбинирование банальных фильтров — это уже хорошо. А он позволяет гораздо больше. Но, оно даже без этого всего — оно хорошо, когда у тебя есть четкая (единая) структура БД. Есть и ситуации когда параметризированные запросы не подходят, — и linq2db тоже имеет ответ на это. Но, этот самый "маппинг" (смысловой) — он же статический. LINQ открывает очень много возможностей, и linq2db — ну, весьма хороший инструмент.
MA> Но, я может не правильно выразился изначально — сам по себе — этот инструмент, каким бы он не был — просто не может быть определяющим.
MA> А в такой универсальной системе — если идти с фиксированной схемой — это имеет одни границы. Они подходят? А если не фиксированной — то применение LINQ вообще ограничится набором фиксированных служебных таблиц, где применение любого linq-провайдера в относительной доли окажется смешным.
MA> PS: Это мое лично мнение, я не навязываю и не претендую на правоту и единство. Просто всему своё место.
Ну я на 1С программировал лет 20. И знаю о чем говорю. Там и SQL даже не вессь стандарт SQL 92 поддерживает. У Linq даже больше возможностей.
Что касается диначмического характера запросов, то как раз Linq удобен для склейки запросов. В отличие от текста. Все типизированно.
Re[6]: linq2db и Убивец 1С
Здравствуйте, Mystic Artifact, Вы писали:
S>> Так например для неопределенных справочников формируется запрос по доступным справочникам. Кстати в C#9 предлагается юнионы (ограничения на типы)
S>>
MA> Название расходится с примером. Это не ограничение на типы — это бред сумасшедшего. Оно просто не нужно. Более того, кому нужно — у тех уже 20 лет как все карты на руках (object, не?). И это довольно широко применяется в .NET все время его существование, но всегда маскируется за типизированными библиотеками. Да, люди экономят байты, там где есть профит. Лучше бы починили Dictionary<TStruct, TKey> где TStruct — 64-битная структура, при этом проседает по скорости раз в 5 по отношению к long.
В TypeScript прекрасно работают и для БД это ограничение на типы без атрибутов можно вводить
S>>В 1С существуют поля неопределенного типа. Это например план счетов и прочее. В таких полях может содержаться тип,ВидСправочника, Ид
S>>https://infostart.ru/public/402038/
MA> Именно с полями неопределенного типа невозможно нормально ничего сделать. Давай их проссумируем — а тут по середине — строка? Это значит, "неверное" значение нужно пропустить или выдать ошибку? Для того, что бы эффективно работать с любыми данными — нужно разобраться с ними, а не скидывать всё в одно болото. Да, это бывает дается не сразу, но в учетке то... не знаю. Ну, ладно. У нас был ещё последний тип по моему вариант, который никогда фактически не использовался. По сути то, нет проблем и динамически структуру БД менять — просто многие преимущества LINQ пропадут. Хотя linq2db останется полезным, т.к. имеет кучу вкусняшек всё равно.
Просто есть тип, по типу и отфильтруем. Это не проблема. А вот linq2db можно под такие задачи и подпелить.
Кстати тот же case https://stackoverflow.com/questions/4244023/select-case-in-linq
Но можно и по человеческо обработать через switch case https://docs.microsoft.com/ru-ru/dotnet/api/system.linq.expressions.switchcase?view=netcore-3.1
S>> Можно создать по такому типу запросы. С ограничением по типу, с выборкой всех типов итд.
S>>Ну и учтиывая патерн матчинг можно и по другому запросы писать и генерировать!
MA> Ничего это не даёт ровным счетом. Есть логическая схема данных. Есть физическая (в БД). Задача — превратить один сформулированный запрос в другой (на SQL). Это вообще задача почти прямого маппинга, тут ни фичи языка, ни LINQ как таковой особой роли не роялят, и решается она достаточно просто. Иногда выглядит кошмарно. Иногда красиво. Последний раз когда я встречал подобную задачу — это было что-то около 150Кб кода на VB.NET. И все только вокруг него ходили и охали и ахали, но ничего кардинального с этим построителем запросов сделать нельзя, а LINQ вообще туда не лезет, потому что запрос полностью динамический, от таблиц, фич клиентов до кол-ва результирующих колонок. На самом деле сделать можно, но тогда разломать прийдется решительно всё. Но при этом LINQ ни в каком виде всё равно не применим. Такова специфика.
MA> Основная сила LINQ открывается в комбинировании уже готовых запросов или подзапросов, особенно построенных динамически. И одного этого на самом деле достаточно. Комбинирование банальных фильтров — это уже хорошо. А он позволяет гораздо больше. Но, оно даже без этого всего — оно хорошо, когда у тебя есть четкая (единая) структура БД. Есть и ситуации когда параметризированные запросы не подходят, — и linq2db тоже имеет ответ на это. Но, этот самый "маппинг" (смысловой) — он же статический. LINQ открывает очень много возможностей, и linq2db — ну, весьма хороший инструмент.
MA> Но, я может не правильно выразился изначально — сам по себе — этот инструмент, каким бы он не был — просто не может быть определяющим.
MA> А в такой универсальной системе — если идти с фиксированной схемой — это имеет одни границы. Они подходят? А если не фиксированной — то применение LINQ вообще ограничится набором фиксированных служебных таблиц, где применение любого linq-провайдера в относительной доли окажется смешным.
MA> PS: Это мое лично мнение, я не навязываю и не претендую на правоту и единство. Просто всему своё место.
Ну я на 1С программировал лет 20. И знаю о чем говорю. Там и SQL даже не вессь стандарт SQL 92 поддерживает. У Linq даже больше возможностей.
Что касается диначмического характера запросов, то как раз Linq удобен для склейки запросов. В отличие от текста. Все типизированно.
S>> Так например для неопределенных справочников формируется запрос по доступным справочникам. Кстати в C#9 предлагается юнионы (ограничения на типы)
S>>
S>>var crazyCollectionFP = new List<int|double|string>{1, 2.3, "bassam"};
S>>MA> Название расходится с примером. Это не ограничение на типы — это бред сумасшедшего. Оно просто не нужно. Более того, кому нужно — у тех уже 20 лет как все карты на руках (object, не?). И это довольно широко применяется в .NET все время его существование, но всегда маскируется за типизированными библиотеками. Да, люди экономят байты, там где есть профит. Лучше бы починили Dictionary<TStruct, TKey> где TStruct — 64-битная структура, при этом проседает по скорости раз в 5 по отношению к long.
В TypeScript прекрасно работают и для БД это ограничение на типы без атрибутов можно вводить
S>>В 1С существуют поля неопределенного типа. Это например план счетов и прочее. В таких полях может содержаться тип,ВидСправочника, Ид
S>>https://infostart.ru/public/402038/
MA> Именно с полями неопределенного типа невозможно нормально ничего сделать. Давай их проссумируем — а тут по середине — строка? Это значит, "неверное" значение нужно пропустить или выдать ошибку? Для того, что бы эффективно работать с любыми данными — нужно разобраться с ними, а не скидывать всё в одно болото. Да, это бывает дается не сразу, но в учетке то... не знаю. Ну, ладно. У нас был ещё последний тип по моему вариант, который никогда фактически не использовался. По сути то, нет проблем и динамически структуру БД менять — просто многие преимущества LINQ пропадут. Хотя linq2db останется полезным, т.к. имеет кучу вкусняшек всё равно.
Просто есть тип, по типу и отфильтруем. Это не проблема. А вот linq2db можно под такие задачи и подпелить.
Кстати тот же case https://stackoverflow.com/questions/4244023/select-case-in-linq
from u in users
let range = (u.Age >= 0 && u.Age < 10 ? "0-25" :
u.Age >= 10 && u.Age < 15 ? "26-40" :
u.Age >= 15 && u.Age < 50 ? "60-100" :
"50+")
group u by range into g
select new { g.Key, Count=g.Count() };Но можно и по человеческо обработать через switch case https://docs.microsoft.com/ru-ru/dotnet/api/system.linq.expressions.switchcase?view=netcore-3.1
S>> Можно создать по такому типу запросы. С ограничением по типу, с выборкой всех типов итд.
S>>Ну и учтиывая патерн матчинг можно и по другому запросы писать и генерировать!
MA> Ничего это не даёт ровным счетом. Есть логическая схема данных. Есть физическая (в БД). Задача — превратить один сформулированный запрос в другой (на SQL). Это вообще задача почти прямого маппинга, тут ни фичи языка, ни LINQ как таковой особой роли не роялят, и решается она достаточно просто. Иногда выглядит кошмарно. Иногда красиво. Последний раз когда я встречал подобную задачу — это было что-то около 150Кб кода на VB.NET. И все только вокруг него ходили и охали и ахали, но ничего кардинального с этим построителем запросов сделать нельзя, а LINQ вообще туда не лезет, потому что запрос полностью динамический, от таблиц, фич клиентов до кол-ва результирующих колонок. На самом деле сделать можно, но тогда разломать прийдется решительно всё. Но при этом LINQ ни в каком виде всё равно не применим. Такова специфика.
MA> Основная сила LINQ открывается в комбинировании уже готовых запросов или подзапросов, особенно построенных динамически. И одного этого на самом деле достаточно. Комбинирование банальных фильтров — это уже хорошо. А он позволяет гораздо больше. Но, оно даже без этого всего — оно хорошо, когда у тебя есть четкая (единая) структура БД. Есть и ситуации когда параметризированные запросы не подходят, — и linq2db тоже имеет ответ на это. Но, этот самый "маппинг" (смысловой) — он же статический. LINQ открывает очень много возможностей, и linq2db — ну, весьма хороший инструмент.
MA> Но, я может не правильно выразился изначально — сам по себе — этот инструмент, каким бы он не был — просто не может быть определяющим.
MA> А в такой универсальной системе — если идти с фиксированной схемой — это имеет одни границы. Они подходят? А если не фиксированной — то применение LINQ вообще ограничится набором фиксированных служебных таблиц, где применение любого linq-провайдера в относительной доли окажется смешным.
MA> PS: Это мое лично мнение, я не навязываю и не претендую на правоту и единство. Просто всему своё место.
Ну я на 1С программировал лет 20. И знаю о чем говорю. Там и SQL даже не вессь стандарт SQL 92 поддерживает. У Linq даже больше возможностей.
Что касается диначмического характера запросов, то как раз Linq удобен для склейки запросов. В отличие от текста. Все типизированно.