Спасибо за замечание. По ошибке, оказалось на YouTube просмотр на сторонних сайтах запрещен по умолчанию. Включать его нужно для каждого видео отдельно.
Но бывает, когда другие моменты настолько важнее целостности, что ее контролем на уровне СУБД можно пренебречь.
Так действительно бывает. Можно попробовать ослабить гарантии в конкретной таблице, возможно этого будет достаточно. Если этого окажется недостаточно, то можно взять для этого конкретного набора данных какую-то более подходящую базу.
Втиснуть-то можно все, но результат превращается в неудобоваримую отвратительно поддерживаемую нелогичную дичь.
Эти данные так же можно отложить в отдельную СУБД, более подходящую.
Но скорее всего в проекте есть еще и более приземленные данные. Их все еще можно хранить в традиционной базе RDBMS.
А если нельзя ?
Нужно до этого дайти. Найти в чем затык. Посмотреть можно ли это просто решить средствами существующего инструмента. Если нет, то применить в этом месте более подходящее.
А если забираться в дебри расширений языка от разных производителей СУБД...
Дебри всегда дебри. Часто даже не больших проектов в них лезть не приходится. Если уж пришлось, то вероятно и при использовании другого инструмента это были бы уже дебри.
Раньше работал в компании, что строили IDE для SQL, как раз в команде code completion.
Мы там прошли через ад, что бы это подсказывать нормально(писал об этом в блоке Парсинг SQL и диалектов). В целом чаще, как мы выяснили набирают 'SELECT FROM tbl', а потом возвращаются в select list и указывают колонку. Когда сначала ставят * легче, потому что скрипт получается валидный, когда нет, все похуже.
Результатом анализа требований проекта может быть понимание того, что для него целостность данных критична.
Как правило, внутри каждого проекта есть данные целостность которых критична. Часто бывает, что целостностью каких-то данных можно принебречь. Если эта возможность как-то развяжит инженерам руки, то можно будет ею воспользоваться.
Если же можно получить и достаточную производительность и целостность всех данных, то лучше получить и то и другое. К тому же снизив сложность найма и упростив общение.
Был интересный момент, когда Google понял, что не способен нанимать инженеров, что способны писать прикладной код распределенных систем совсем без гарантий. Даже google.
Кстати, помимо того же JSON многие реляционные базы поддерживают и разного рода объекты: массивы, словари или просто объекты с наборами полей.
Тут бы все работало,если бы бизнесы имели цену и был их нормальный рынок.
Ну то есть: 20 лет строишь бизнес, зарабатываешь примерно как твой топ сотрудник, может немного больше, может даже немного меньше. Но потом продаешь бизнес. Я не говорю о миллиардах, но успешный бизнес, что делает деньги и имеет 40-50 сотрудников, вполне может стоить несколько миллионов долларов там, где бизнесы частенько покупают и продают.
Однажды, много лет назад решал задачу избавления от VB.NET.
Примерно такой же объем кода и примерно такой же результат по трудозатратам. Только все это было в эру до Roslyn... Я тогда извернулся то ли через dotPeek, то ли через ILDasm, то ли через Reflector. Короче собрал VB в dll, разобрал уже в C#. Прошло довольно гладко. Что-то ещё глазами по мелочи подправил и все запело.
Несколько раз, перед необходимостью очередного допила мой, или чей-то еще воспаленный под вечер мозг предлгал эту идею. На утро, к счастью, мы никогда не приступали к такому решению.
Меня дико впечетляло как ANTLR разруливал различные сложные граничные кейсы, которые реально встречались в наших грамматиках. Вырастить свой генератор парсеров для обработки их всех потребовало бы несравнимо больше усилий. Хотя, будь я проклят, думаю у меня бы аж глаза искрили вдохновением от такой задачи первые несколько недель!
Всем сердцем люблю Resharper и многие функции, что он дает, но какое-то время назад был вынужден его отключить именно из-за получающихся тормозов.
Прикладываю иногда кусочек воли к переходу на rider. Нравится еще больше, но перейти не могу. За что себя и ругаю.
К сожалению, у меня просто нет знакомых специалистов уровня Сергея, только в области Postgres.
Хотя сам люблю Postgres всем сердцем.
Спасибо большое, рад что интереснее)
@AlanDentonэто будет потрясающий стрим! Сделаем это!
Линейка продуктов dbForge
Был лидом команды, что делала Code Completion какое-то время.
Цикл статей "Дополняя SQL" в профиле как раз про те времена.
Спасибо, надеюсь будет полезно и понятно
Большое спасибо за обратную связь!
Спасибо за замечание. По ошибке, оказалось на YouTube просмотр на сторонних сайтах запрещен по умолчанию. Включать его нужно для каждого видео отдельно.
Исправил.
Так действительно бывает. Можно попробовать ослабить гарантии в конкретной таблице, возможно этого будет достаточно. Если этого окажется недостаточно, то можно взять для этого конкретного набора данных какую-то более подходящую базу.
Эти данные так же можно отложить в отдельную СУБД, более подходящую.
Но скорее всего в проекте есть еще и более приземленные данные. Их все еще можно хранить в традиционной базе RDBMS.
Нужно до этого дайти. Найти в чем затык. Посмотреть можно ли это просто решить средствами существующего инструмента. Если нет, то применить в этом месте более подходящее.
Дебри всегда дебри. Часто даже не больших проектов в них лезть не приходится. Если уж пришлось, то вероятно и при использовании другого инструмента это были бы уже дебри.
Ему тяжело, но он справляется(рекурсивные CTE)
На практике работал с такими данными, но обычно они обрабатывались до +/- реляционных до попадения в базу.
Раньше работал в компании, что строили IDE для SQL, как раз в команде code completion.
Мы там прошли через ад, что бы это подсказывать нормально(писал об этом в блоке Парсинг SQL и диалектов). В целом чаще, как мы выяснили набирают 'SELECT FROM tbl', а потом возвращаются в select list и указывают колонку. Когда сначала ставят * легче, потому что скрипт получается валидный, когда нет, все похуже.
Но в целом притензия здравая.
Результатом анализа требований проекта может быть понимание того, что для него целостность данных критична.
Как правило, внутри каждого проекта есть данные целостность которых критична. Часто бывает, что целостностью каких-то данных можно принебречь. Если эта возможность как-то развяжит инженерам руки, то можно будет ею воспользоваться.
Если же можно получить и достаточную производительность и целостность всех данных, то лучше получить и то и другое. К тому же снизив сложность найма и упростив общение.
Был интересный момент, когда Google понял, что не способен нанимать инженеров, что способны писать прикладной код распределенных систем совсем без гарантий. Даже google.
Кстати, помимо того же JSON многие реляционные базы поддерживают и разного рода объекты: массивы, словари или просто объекты с наборами полей.
P.S. Постарался поправить пунктуацию.
Местами он многословен, согласен
Тут бы все работало,если бы бизнесы имели цену и был их нормальный рынок.
Ну то есть: 20 лет строишь бизнес, зарабатываешь примерно как твой топ сотрудник, может немного больше, может даже немного меньше. Но потом продаешь бизнес. Я не говорю о миллиардах, но успешный бизнес, что делает деньги и имеет 40-50 сотрудников, вполне может стоить несколько миллионов долларов там, где бизнесы частенько покупают и продают.
Однажды, много лет назад решал задачу избавления от VB.NET.
Примерно такой же объем кода и примерно такой же результат по трудозатратам. Только все это было в эру до Roslyn... Я тогда извернулся то ли через dotPeek, то ли через ILDasm, то ли через Reflector. Короче собрал VB в dll, разобрал уже в C#. Прошло довольно гладко. Что-то ещё глазами по мелочи подправил и все запело.
Сможете поделится кейсом в котором пригодился? Думаю реальный кейс окажется полезен «будущим поколениям»
Меня дико впечетляло как ANTLR разруливал различные сложные граничные кейсы, которые реально встречались в наших грамматиках. Вырастить свой генератор парсеров для обработки их всех потребовало бы несравнимо больше усилий. Хотя, будь я проклят, думаю у меня бы аж глаза искрили вдохновением от такой задачи первые несколько недель!
Прикладываю иногда кусочек воли к переходу на rider. Нравится еще больше, но перейти не могу. За что себя и ругаю.