Здравствуйте, vdimas, Вы писали:

V>Как это выглядит в GUI?
Позже покажу.

S>>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.

V>У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))
V>Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.
V>Затем создай визардом новый запрос, просто накидай поля с двух связанных таблиц, убедись в режиме конструктора, что таблицы связаны по внешнему ключу как ты и указал в схеме данных до этого.

А у вас не было возможности открыть SharePoint и посмотреть как это сделано там? Объяснять бесполезно, надо попробовать. Вроде бы, мелкомягкие дают триальный доступ (если зарегистрироваться). Раньше попадались инстансы demo/demo, но дни те прошли, увы.

Вообще, SharePoint это очень хороший пример того, о чём я говорю.

С одной стороны нечего там мышкой «накидывать». Надо задавать свойства. А с другой стороны, он реализует пользовательскую систему метафор, а не программистскую. Сравнить их очень просто: я ещё ни разу не видел, чтобы юзеры без специального образования с Access'ом разбирались так же быстро, как с ШП. Как только продвинутый юзер посоздаёт пару «списков» (Lists, аналог таблицы в ШП), он очень быстро начинает делать справочники, заботиться о нормализации данных и вообще — проектировать БД. И... тут же упирается в ограничения реализации ШП. Но как маяк, задающий вектор направления no-code/low-code, ШП, повторюсь, неплохой пример.


S>>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
V>От твоего директора, который полез программировать и не справился.

??? Вообще ничего не понял.

Во-первых, там была SQL БД.

Во-вторых, SQL это не ЯП. Это язык управления БД. В том числе для запросов. Я слышал, что когда-то SQL (в командной строке) был аналогом... ну, любого современного продукта для организованного хранения данных. В том смысле, что это был пользовательский интерфейс (а не как сейчас — DSL, на котором 99.9% запросов конструируют и отправляют роботы). Причём, пользовательский в прямом значении этого слова. Считалось, что компьютерно грамотный счетовод с его помощью будет отчёты писать. Так что — директор не «полез программировать», а просто вернулся к пользовательским корням.

В-третьих, он не «не справился», а просто не знал синтаксис одной конструкции. Да я и сам не знал, я на тот момент с базами дел не имел. Просто попробовал перебрать !=, <>, второе сработало.

В-четвёртых, яжпрограммист уже трудился и моя помощь ему ничего не стоила, если не считать 10 минут рабочего времени.


S>>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.

V>И что теперь?
V>Так и продолжать забивать гвозди микроскопом?
V>А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
V>

V>FOREIGN KEY (CustomerId)  REFERENCES Customers (Id)
V>

V>вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
V>Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
V>CustomerId^{➔Customers.Id}

Я не знаю, как ещё объяснить. Я считаю (возможно, ошибочно), что «мышкой протянуть» — это искать под фонарём. Это чисто формальная попытка создать дружественный UI. Сделанная на отмирись. А по-настоящему дружественный UI это колонки-ссылки.

V>No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.

Правильный no-code ДОЛЖЕН сделать низлежащие форматы/языки АБСОЛЮТНО не важными. Иначе это будет тупой маппинг низлежащего формата на уровень UI, со всеми врождёнными особенностями.

Например, триггер для юзера — это не сами знаете что, а, например, отправка сообщения в телегу. Очень удобно, кстати. Пользователи такие вещи обожают. Представляете — вы можете сделать свою Джиру за час, вообще не программируя, при этом интегрироваться с административной базой (HR) и будут у вас уведомления в мессенджер приходить. Зачем вообще делать свою Джиру? А почему бы нет, если любой менеджер, не программируя, может за час управиться, при этом гибко подстроив под свои процессы (которые у всех разные). А ещё лучше — скачать шаблон issue tracker и донастроить его.

V>Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
V>Позорище это, а не достижение.

Немножко пофилософствую.

Смотрите, винды всегда были проприетарными. Исходники давали только правительствам и особо доверенным партнёрам. А Андроид — опенсорсный. Кто из них более открыт?

Я скажу так, что это большой и сложный вопрос. В виндах в комплекте из коробки идёт Regedit, например. И винды когда-то поощряли хранение данных в реестре. С именованными типизированными значениями. В стоковом Андроиде как подкрутить одну из тысяч мелочей, если понадобится? Качать аппу из апстора. Хотя под капотом там наверняка можно одну запись где-нибудь поменять. Но нет инструмента — и тащи аппу. С рекламой, занимающую место и так далее.

Так вот. Применительно к управлению данными открытость не в том, чтобы был импорт-экспорт (хотя это, конечно, вещь нужная и полезная). А в том, чтобы доступ к данным у юзера был напрямую и в удобном виде. Чтобы он мог их как угодно повертеть — сделать выборку, отфильтровать, отсортировать, сгруппировать, выбрать нужное представление — не прибегая к импорту-экспорту.

V>Сдаётся мне, рано или поздно OLE переизобретут. ))

S>>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?

V>Разумеется!
V>В таблице Менделеева есть естественный ключ {атомный-номер}.

Я имел в виду, например, таблицы из этого раздела.

S>>Или в почтовом клиенте/органайзере они есть?
V>Почти всегда.

V>Дело в том, что реляционные хранилища — они очень дорогие, неэффективные и т.д.
V>Это при оценке их эффективности снизу.
V>Они делают кучу на первый взгляд ненужных телодвижений при простой записи и даже, блин, ты будешь ржать — куча каких-то телодвижений даже для простого, блин, чтения.
V>Кароч, всё через анус, всё не как у нормальных людей.

В каком смысле — дорогие и неэффективные?

V>Ладно, сорри.
V>Твой стиль напоминает сочинение из разряда "как я провёл лето".

Я просто хотел, чтобы вы забыли на минутку, что вы разработчик с 30 годами сикуля за плечами, и посмотрели глазами юзера.

V>================
V>Такое складывается ощущение, что ваше поколение не то что не стремится поддерживать цену своим словам, а просто не в курсе про существование такого критерия оценки личности.
V>- Говори по существу.
V>- Любые подробности должны тем или иным образом относиться к делу. Растекаться мыслью по древу тоже надо уметь.
V>- Не злоупотребляй оценочными суждениями, а лучше вообще от них отказаться в технических рассуждениях.
V>Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?

Э-э? А какие подробности к делу не относятся? Моё поколение ещё учили, не знаю, как последующие, что полезно на конкретных примерах обсуждать, а не клеить ярлыки. Поэтому я и беру конкретные примеры.