В принципе вы правы с параметрами IS NULL он разберется наверное.
Но тут конечно нюанс не начнет ли он CROSS APPLY безусловно nested loop'ом выполнять.
То есть если вы сделаете:
SELECT FROM Product pr CROSS APPLY balance('01.01.2019',pr.id,NULL).
Не начнет ли он бежать по Product и рассчитывать подзапрос для каждого товара, сумеет ли он из product=@productid hash probe сделать. Надо будет потестировать.
Но в любом случае вы же понимаете, что это жесткий хак и чтобы его нормально использовать, вам придется все представления такими хаками делать. Плюс возможно с WITH RECOMPILE, чтобы MS SQL не дурел с планами.
Тут дело в том что, в части случаев мы не контролируем шрифт. Как например в той же IDEA. И даже если плагином это удастся сделать, выглядеть все равно вычурно будет.
На самом деле там не сложно и маленькие буквы сделать с режимом обратной совместимости, единственный вопрос как сделать, чтобы модули с маленькими буквами могли подключать модули с большими буквами. Можно понятно просто в модуле сделать опцию, но это не очень удобно будет. Но думаю в будущем разберемся.
Ну какие то мобильные устройства появились. Но непонятно с учетом мобильной версии или нет. То есть m.habr.com тоже починили? Потому как его вроде пока не видно (хотя это не показатель)
Не передергивайте. Я говорил про классы, а не про какие-то мифические сущности. Никакого класса Товар на Складе нет. Таблица с ключами Товар, Склад есть. Но таблица это понятие из физической модели, а классы из логической. То есть про таблицы знает только DBA, разработчик знает только про классы.
Хотя опять таки вопрос, что вы понимаете под сущностью в программировании. Жду ссылку на описание этого понятия.
А я и не говорю, что сущность соответствует таблице. Я говорю, что сущность — это все, чему соответствует таблица.
А можно тогда ссылку какую нибудь, где написано что такое сущность в программировании. А то в википедии класс и объект есть, а никакой сущности там нет.
Ровно наоборот же: в типовой реализации ORM эта сущность будет:
А в системном программировании за такие классы вам любой архитектор руки оторвет. Наличие таких классов, скорее характеризует ORM не с очень хорошей стороны, чем что-то доказывает.
Неа, я этого не предлагал. Например, мне кажется, что в контексте вашей системы очень легко выделить «сущность»: это все, чему соответствует явная (а не материализованная) таблица в БД.
У нас можно написать TABLE objects (Object). И объекты всех классов (как и свойства с одним параметром) лягут в одну таблицу. Ну и есть еще числа, даты, которые тоже по сути сущности. Поэтому говорить что сущность соответствует таблице не совсем правильно. Хотя какая то логика тут есть.
К сожалению, софистикой занимаетесь вы, отказываясь признавать что-то сущностью, но при этом не дав сначала формального определения, что сущностью считается.
Сущность — это объект. То есть ровно тоже самое что подразумевается под объектом в том же C#. И вы же понимаете, что никаких объектов «Товар на складе» в C# нет.
Ну то есть давайте абстрагируем сущность до того чтобы она перестала что-либо значить. Потому как если связь тоже сущность, тогда все что угодно — сущность и бритва Оккама теряет смысл. Гениально. Софистика в чистом виде.
Или, например, классы и модули могут решать задачи функциональной группировки разных объектов.
То есть классы и модули отвечают за одно и то же (что не отменяют что у них еще есть и другие обязанности). Что в общем случае хреново с архитектурной точки зрения.
SQL никогда не был первичен. Более того первые реализации вообще не под SQL были. Тут как раз работала бритва оккама — в которой не надо выбирать это товар лежит на складе или склад содержит товар.
Принцип «бритвы Оккама» состоит в следующем: если некое явление может быть объяснено двумя способами: например, первым — через привлечение сущностей (терминов, факторов, фактов и проч.) А, В и С, либо вторым — через сущности А, В, С и D, — и при этом оба способа дают одинаковый результат, то следует предпочесть первое объяснение. Сущность D в этом примере лишняя, и её привлечение избыточно.
Ну так и в пределах одного модуля могут быть функции, которые можно сгруппировать по их назначению. Зачем относить их неявно к одной глобальной сущности, если можно отнести явно к нескольким конкретным в соответствии с предметной областью?
Если у свойств одинаковый / семантически близкий функционал их лучше выделить в отдельный модуль. Благо lsFusion отлично подходит для работы с такими микромодулями. Ну или просто в одном модуле рядом положить. В некоторых случаях сгруппировать в одном классе может быть еще лучше, но это уже лучшее враг хорошего.
Так там вся статья что есть несколько разных трактовок инкапсуляции.
Инкапсуляция зачастую рассматривается как понятие, присущее исключительно объектно-ориентированному программированию (ООП), но в действительности обширно встречается и в других (см. подтипизация на записях и полиморфизм записей и вариантов)
Лично я чисто про ООП'ую говорю (сокрытие не обязательно, это опять таки перпендикулярная штука).
Заводить по модулю на каждую бизнес-сущность? Можно, конечно, но избыточно же.
Вы же понимаете что наличие параметров одинакового класса, еще не означает семантическую связь между свойствами? Корреляция возможно и есть, но далеко не всегда.
И размазывать логику функциональной группировки на две абстракции модули и классы / кортежи классов, это по вашему не избыточно?
Повторюсь еще раз:
Это неплохой синтаксический сахар. Но за функциональную группировку должны по хорошему отвечать модули, это их прямая обязанность. Для всех остальных элементов — это просто побочный эффект.
И наличие общего по классу параметра, еще не означает одинаковую или даже сильно похожую логику свойств.
Так, а зачем тогда view вообще нужен?
Но тут конечно нюанс не начнет ли он CROSS APPLY безусловно nested loop'ом выполнять.
То есть если вы сделаете:
SELECT FROM Product pr CROSS APPLY balance('01.01.2019',pr.id,NULL).
Не начнет ли он бежать по Product и рассчитывать подзапрос для каждого товара, сумеет ли он из product=@productid hash probe сделать. Надо будет потестировать.
Но в любом случае вы же понимаете, что это жесткий хак и чтобы его нормально использовать, вам придется все представления такими хаками делать. Плюс возможно с WITH RECOMPILE, чтобы MS SQL не дурел с планами.
На самом деле там не сложно и маленькие буквы сделать с режимом обратной совместимости, единственный вопрос как сделать, чтобы модули с маленькими буквами могли подключать модули с большими буквами. Можно понятно просто в модуле сделать опцию, но это не очень удобно будет. Но думаю в будущем разберемся.
Хотя опять таки вопрос, что вы понимаете под сущностью в программировании. Жду ссылку на описание этого понятия.
А можно тогда ссылку какую нибудь, где написано что такое сущность в программировании. А то в википедии класс и объект есть, а никакой сущности там нет.
А в системном программировании за такие классы вам любой архитектор руки оторвет. Наличие таких классов, скорее характеризует ORM не с очень хорошей стороны, чем что-то доказывает.
У нас можно написать TABLE objects (Object). И объекты всех классов (как и свойства с одним параметром) лягут в одну таблицу. Ну и есть еще числа, даты, которые тоже по сути сущности. Поэтому говорить что сущность соответствует таблице не совсем правильно. Хотя какая то логика тут есть.
Сущность — это объект. То есть ровно тоже самое что подразумевается под объектом в том же C#. И вы же понимаете, что никаких объектов «Товар на складе» в C# нет.
То есть классы и модули отвечают за одно и то же (что не отменяют что у них еще есть и другие обязанности). Что в общем случае хреново с архитектурной точки зрения.
Проблема в том что: «Не следует привлекать новые сущности без крайней на то необходимости». А тут не то что крайней, тут вообще необходимости нету.
Если у свойств одинаковый / семантически близкий функционал их лучше выделить в отдельный модуль. Благо lsFusion отлично подходит для работы с такими микромодулями. Ну или просто в одном модуле рядом положить. В некоторых случаях сгруппировать в одном классе может быть еще лучше, но это уже лучшее враг хорошего.
Как разные? Одну же — задачу функциональной группировки.
Лично я чисто про ООП'ую говорю (сокрытие не обязательно, это опять таки перпендикулярная штука).
Вы же понимаете что наличие параметров одинакового класса, еще не означает семантическую связь между свойствами? Корреляция возможно и есть, но далеко не всегда.
И размазывать логику функциональной группировки на две абстракции модули и классы / кортежи классов, это по вашему не избыточно?
Вы сейчас про инкапсуляцию в ООП, или про абстрактную инкапсуляцию, которая все обо всем?
Это неплохой синтаксический сахар. Но за функциональную группировку должны по хорошему отвечать модули, это их прямая обязанность. Для всех остальных элементов — это просто побочный эффект.
И наличие общего по классу параметра, еще не означает одинаковую или даже сильно похожую логику свойств.