я понял, что каждый останется при своем мнении. Ну пусть так. Вы лучше пример задачи приведите, в которой нельзя было (или существенно сложнее) обойтись одним NULL, как это сделано в СУБД.
Я например, привел примеры ошибок и сомнительных архитектурных решений, созданные так или иначе:
— на уровне платформы
— на уровне прикладных типовых решений от вендора
— в работе прикладного программиста, адаптирующего решение
По-моему язык и СУБД сравнивать немного некорректно. То есть все вот эти MS SQL, Postgree, Oracle по-вашему живут какой-то неправильной жизнью? Но да ладно, по существу.
«запрет не заполненных значений», в MS SQL в типах колонок есть «not Null»
Это несколько разное. Стоит в 1С галка или не стоит у измерения, но там уже «not Null» всегда. Галочка эта не поможет — туда нельзя будет незаполненные значения записывать, а это надо делать. Да, так или иначе можно всегда перед записью проверять и все пустые ссылки превращать в Неопределено. Но «из коробки» такого решения нет и типовые продукты этим тоже не заморачиваются вроде бы.
А что произойдёт, если изменят простой ссылочный тип? Вообще «тип расширят», это неправильное понимание, это составной тип расширяется подтипами, а простой тип — заменяют.
Ну да, только колонка с простым типом это колонка в описании типов которой он один. Не кажется, что это всего лишь частный случай одного и того же?
В своем примере вы не аналогичный пример поставляете. У вас тип-произведение. То есть одно поле вы заменяете двумя. Мы же говорим про тип-сумму, который остается одним полем, но расширяется.
Пример из языка (c#, в delphi такое тоже это есть):
1. Было:
class Foo{}
//...
Foo x = new Foo();
Foo y = null;
2. Стало:
interface IFooBar {}
class Foo:IFooBar {}
class Bar:IFooBar {}
//...
IFooBar x = new Foo();
IFooBar y = null;
Тип переменных x, y расширили. Но они могут также принимать прежние значения. Вот это и есть ближайший аналог составного типа 1С. При этом y как принимала значение null как пустая ссылка, так и принимает. Никаких новых пустых ссылок система не привнесла.
Можно сколько угодно говорить про Неопределено в 1С — что это конкретное значение, а пустые ссылки — еще более конкретные значения. Но все это софистика, на мой сугубо субъективный взгляд.
Жить с этим можно, но принцип бритвы Оккама нарушен.
«пустая строка» и Null — это нормально с РСУБД
А все эти навороты с кучей пустых типов мне непонятны, хотя я разбираюсь в этом (надеюсь).
Посмотрите чему равен Артикул а запросе в справочнике Номенклатура у группы в какой-нибудь типовой конфигурации. Ну это так, чтобы просто не думали, что NULL только в соединениях бывает.
Помнится как внезапно с выходом очередной платформы сменился тип у полей Субконто таблиц регистров бухгалтерии, если у счета нет такого уровня субконто.
Другой случай, когда пользователь выбрал конкретный тип у реквизита составного типа, но сам реквизит не заполнил. Записалась пустая ссылка. Пришлось искать в чем ошибка. Оказалось, что логика была рассчитана на Неопределено.
Есть и обратный пример, где в скидках при незаполненном измерении система подставляла ДоговорыКонтрагентов.ПустаяСсылка. Почему именно ее из нескольких выбрали и почему не Неопределено?
Наконец представьте себе, что у вас есть таблица с простым ссылочным типом и вам в логике нужен запрос, отбирающий заполненные данные. Я думаю там будет условие что-то типа Реквизит<>ЗНАЧЕНИЕ(ТипЭтогоСамогоРеквизита.ПустаяСсылка)
Что произойдет, когда тип расширят до составного? Логика нарушится.
Мне кажется живых примеров достаточно.
А вот если был бы ТОЛЬКО один NULL, как в большинстве промышленных СУБД — таких проблем бы не возникало.
среда разработки:
git — только завозят
юнит-тестирования — нет
расширяемость плагинами конфигуратора — нет
в расширениях напрочь отсутствует автоподстановка
в языке:
ленивые вычисления — отсутствуют
работа с объектами ТОЛЬКО через строки — этого зато полно
унификации интерфейсов коллекций — нет
язык запросов — слабый SELECT
и довольно спорное решение, когда в одной колонке таблицы в разных записях может встретиться ПустаяСсылка, Неопределено и NULL
механизм исключений — довольно слабый
освобождение внешних ресурсов — не контролируется
И я о том же. Система давно уже выросла из макросов, доступных рядовому бухгалтеру. Вендор уже не тянет по всем фронтам одновременно. Хорошо хоть потихоньку начинает переходить на современные технологии.
Но очень неохотно...
По поводу файловой версии не понял. Так это вообще их внутреннее детище. Уж там точно внедряй что хочешь.
И по поводу ПолеHTML можно было реализовать ОБА варианта.
Гораздо эффективнее было бы отдать такие вещи в открытое сообщество как раз
Имхо, основной недостаток 1с в закрытости системы. Нет, прикладной язык открыт. Но платформа жёстко закрыта.
А система всё сильнее развивается. Порог входа растет. И вендор не успевает за прогрессом.
Сделали расширения. Неплохо. Но ошибок куча. Просят сделать более управляемые индексы в базе — идите лесом. Недавно выкатили функции в запросах, которые вроде бы есть в каждой СУБД.
И вот, понимая это, уже вендор развивает не конфигуратор, а EDT, не хранилище конфигураций, а git.
Мое мнение следующей большой версией будет система на инфраструктуре Java. Возможно со своим языком.
Извините за оффтоп.
Мне также. Но еще мне кажется, что дело именно в «кто знаком с SQL»
Неизвестно как пошло бы дело, если бы я вместо SQL учил бы какой-нибудь LINQ и только его.
Дело привычки, мне кажется.
признаю свою вину, средняя таблица albums_musicians все испортила
и пока «сходу» без подзапроса не вышло:
select distinct m.name
from musicians as m
left join
(select am.musician_id, a.year, a.id
from albums_musicians as am
left join albums as a on (a.id = am.album_id)) as temptable
on (m.id = temptable.musician_id) and (temptable.year = 2020)
where temptable.id is null
order by m.name
select m.name
from musicians as m
left join albums_musicians as am on m.id = am.musician_id
left join albums as a on (a.id = am.album_id)
group by m.name, m.id
having count(case when a.year = 2020 then a.id end)=0
order by m.name
нет, он попадет в эту выборку со своим альбомом 2020 года
select distinct m.name
from musicians as m
left join albums_musicians as am on m.id = am.musician_id
left join albums as a on (a.id = am.album_id) and (a.year = 2020)
select distinct m.name
from musicians as m
left join albums_musicians as am on m.id = am.musician_id
left join albums as a on (a.id = am.album_id) and (a.year = 2020)
where a.id is null
order by m.name
Что-то мне кажется в п.10 не решается вопрос «все исполнители, которые не выпустили альбомы в 2020 году»
Код
select distinct m.name
from musicians as m
left join albums_musicians as am on m.id = am.musician_id
left join albums as a on a.id = am.album_id
where not a.year = 2020
order by m.name
выдаст музыкантов, у которых есть альбомы не в 2020, независимо от того, выпускали они альбом в 2020 или нет
и вот эти все уровни изоляции транзакций
А почему в 1с глупо хранить базу?
1с разные бывают. Ну и синхронизация тоже возможна
Я например, привел примеры ошибок и сомнительных архитектурных решений, созданные так или иначе:
— на уровне платформы
— на уровне прикладных типовых решений от вендора
— в работе прикладного программиста, адаптирующего решение
Это несколько разное. Стоит в 1С галка или не стоит у измерения, но там уже «not Null» всегда. Галочка эта не поможет — туда нельзя будет незаполненные значения записывать, а это надо делать. Да, так или иначе можно всегда перед записью проверять и все пустые ссылки превращать в Неопределено. Но «из коробки» такого решения нет и типовые продукты этим тоже не заморачиваются вроде бы.
Ну да, только колонка с простым типом это колонка в описании типов которой он один. Не кажется, что это всего лишь частный случай одного и того же?
В своем примере вы не аналогичный пример поставляете. У вас тип-произведение. То есть одно поле вы заменяете двумя. Мы же говорим про тип-сумму, который остается одним полем, но расширяется.
Пример из языка (c#, в delphi такое тоже это есть):
1. Было:
2. Стало:
Тип переменных x, y расширили. Но они могут также принимать прежние значения. Вот это и есть ближайший аналог составного типа 1С. При этом y как принимала значение null как пустая ссылка, так и принимает. Никаких новых пустых ссылок система не привнесла.
Можно сколько угодно говорить про Неопределено в 1С — что это конкретное значение, а пустые ссылки — еще более конкретные значения. Но все это софистика, на мой сугубо субъективный взгляд.
Жить с этим можно, но принцип бритвы Оккама нарушен.
А все эти навороты с кучей пустых типов мне непонятны, хотя я разбираюсь в этом (надеюсь).
Посмотрите чему равен Артикул а запросе в справочнике Номенклатура у группы в какой-нибудь типовой конфигурации. Ну это так, чтобы просто не думали, что NULL только в соединениях бывает.
Помнится как внезапно с выходом очередной платформы сменился тип у полей Субконто таблиц регистров бухгалтерии, если у счета нет такого уровня субконто.
Другой случай, когда пользователь выбрал конкретный тип у реквизита составного типа, но сам реквизит не заполнил. Записалась пустая ссылка. Пришлось искать в чем ошибка. Оказалось, что логика была рассчитана на Неопределено.
Есть и обратный пример, где в скидках при незаполненном измерении система подставляла ДоговорыКонтрагентов.ПустаяСсылка. Почему именно ее из нескольких выбрали и почему не Неопределено?
Наконец представьте себе, что у вас есть таблица с простым ссылочным типом и вам в логике нужен запрос, отбирающий заполненные данные. Я думаю там будет условие что-то типа Реквизит<>ЗНАЧЕНИЕ(ТипЭтогоСамогоРеквизита.ПустаяСсылка)
Что произойдет, когда тип расширят до составного? Логика нарушится.
Мне кажется живых примеров достаточно.
А вот если был бы ТОЛЬКО один NULL, как в большинстве промышленных СУБД — таких проблем бы не возникало.
git — только завозят
юнит-тестирования — нет
расширяемость плагинами конфигуратора — нет
в расширениях напрочь отсутствует автоподстановка
в языке:
ленивые вычисления — отсутствуют
работа с объектами ТОЛЬКО через строки — этого зато полно
унификации интерфейсов коллекций — нет
язык запросов — слабый SELECT
и довольно спорное решение, когда в одной колонке таблицы в разных записях может встретиться ПустаяСсылка, Неопределено и NULL
механизм исключений — довольно слабый
освобождение внешних ресурсов — не контролируется
З.Ы. — но вообще так толсто, что даже не смешно
И я о том же. Система давно уже выросла из макросов, доступных рядовому бухгалтеру. Вендор уже не тянет по всем фронтам одновременно. Хорошо хоть потихоньку начинает переходить на современные технологии.
Но очень неохотно...
По поводу файловой версии не понял. Так это вообще их внутреннее детище. Уж там точно внедряй что хочешь.
И по поводу ПолеHTML можно было реализовать ОБА варианта.
Гораздо эффективнее было бы отдать такие вещи в открытое сообщество как раз
Имхо, основной недостаток 1с в закрытости системы. Нет, прикладной язык открыт. Но платформа жёстко закрыта.
А система всё сильнее развивается. Порог входа растет. И вендор не успевает за прогрессом.
Сделали расширения. Неплохо. Но ошибок куча. Просят сделать более управляемые индексы в базе — идите лесом. Недавно выкатили функции в запросах, которые вроде бы есть в каждой СУБД.
И вот, понимая это, уже вендор развивает не конфигуратор, а EDT, не хранилище конфигураций, а git.
Мое мнение следующей большой версией будет система на инфраструктуре Java. Возможно со своим языком.
Извините за оффтоп.
Почему не смогут? D будет также молчать, т.к. видит только две шапки разного цвета. Это понимает C и по шапке B называет свой цвет
В каком таком классе. Где тут классы?
Неизвестно как пошло бы дело, если бы я вместо SQL учил бы какой-нибудь LINQ и только его.
Дело привычки, мне кажется.
и пока «сходу» без подзапроса не вышло:
и тут его «настигнет» условие
которое он не преодолеет и в итоге его не будет
Код
выдаст музыкантов, у которых есть альбомы не в 2020, независимо от того, выпускали они альбом в 2020 или нет
P.S. В данном случае эта избыточность вполне оправдана
Так уже не пишут.
В асинхронном стиле:
ДиалогВыбора.Показать(...)
В интернете полно примеров