Сообщение Re[8]: Опять поднимают про low-code и помоечку для средняков от 18.09.2021 10:22
Изменено 18.09.2021 11:01 vdimas
Re[8]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Shtole, Вы писали:
V>>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
S>Например, через формульные колонки и колонки-ссылки.
Как это выглядит в GUI?
S>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))
Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.
Затем создай визардом новый запрос, просто накидай поля с двух связанных таблиц, убедись в режиме конструктора, что таблицы связаны по внешнему ключу как ты и указал в схеме данных до этого.
V>>Вызов тыжпрограммиста 1С обходится слишком дорого.
S>Так вроде про SQL-запросы речь шла?
Речь наоборот шла про то, чтобы юзверю не надо было учить SQL, как не надо его учить для построения приложений в MS Access.
А вызов "надомного программиста" всегда будет стоить чудовищно дорого.
Расценки вызовов 1С поддержки тому подтверждение.
S>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
От твоего директора, который полез программировать и не справился.
V>>Это та самая автоматизация рутины.
V>>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
S>Так дело же не в том, что «мышкой нащёлкать».
Для no-code — именно в этом.
S>Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее.
Нельзя.
Для юзверя это будет что-то вроде программирования на ассемблере.
S>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
И что теперь?
Так и продолжать забивать гвозди микроскопом?
А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
CustomerId➔Customers.Id
Меня за мои почти 30 лет карьеры плоский текст задолбал, если честно.
Воз и ныне там, с чего начинал когда-то — так всё и есть до сих пор.
А вот это г-но мамонта полувековой давности в скриптах SQL — банальная роспись индустрии в недееспособности.
No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.
Их можно будет подменять, не трогая "верхней" функциональности.
А сейчас всё пляшет от языка и только от него.
И в самих языках наблюдается отчётливый кризис жанра. ))
"Новейшие" языки пытаются изобрести то, что изобретено еще в 70-80-90-е.
Всё вместе, в некотором смысле, деградация.
Плохая интероперабельность.
Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
Позорище это, а не достижение.
Сдаётся мне, рано или поздно OLE переизобретут. ))
S>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?
Разумеется!
В таблице Менделеева есть естественный ключ {атомный-номер}.
В таблице изотопов будет составной ключ {атомный-номер, массовое-число}, при этом поле "атомный-номер" мы зададим еще внешним ключом к таблице Менделеева, а значит по нему автоматически будет создан индекс.
S>Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей?
1. От незнания.
2. От ничтожного размера хранимых данных.
S>Или в почтовом клиенте/органайзере они есть?
Почти всегда.
S>Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля.
Правильно спросили.
Перевожу вопрос на русский язык:
"Вы, дядя, если не дурак, то уж точно заблудились, бо в реляционной БД имеет смысл хранить только реляционные данные. В противном случае воспользуйтесь, пожалуйста, другим видом хранилища".
Дело в том, что реляционные хранилища — они очень дорогие, неэффективные и т.д.
Это при оценке их эффективности снизу.
Они делают кучу на первый взгляд ненужных телодвижений при простой записи и даже, блин, ты будешь ржать — куча каких-то телодвижений даже для простого, блин, чтения.
Кароч, всё через анус, всё не как у нормальных людей.
Но когда у нас есть связанные данные на гига- и терабайты, когда эффективность оцениваем сверху (гигабайты данных по результатам работы оптового предприятия мы получали уже в 90-х), то ничего лучше реляционных хранилищ человечество пока не придумало.
S>Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
Ладно, сорри.
Твой стиль напоминает сочинение из разряда "как я провёл лето".
================
Такое складывается ощущение, что ваше поколение не то что не стремится поддерживать цену своим словам, а просто не в курсе про существование такого критерия оценки личности.
— Говори по существу.
— Любые подробности должны тем или иным образом относится к делу. Растекаться мыслью по дереву тоже надо уметь.
— Не злоупотребляй оценочными суждениями, а лучше вообще от них отказаться в технических рассуждениях.
Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?
V>>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
S>Например, через формульные колонки и колонки-ссылки.
Как это выглядит в GUI?
S>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))
Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.
Затем создай визардом новый запрос, просто накидай поля с двух связанных таблиц, убедись в режиме конструктора, что таблицы связаны по внешнему ключу как ты и указал в схеме данных до этого.
V>>Вызов тыжпрограммиста 1С обходится слишком дорого.
S>Так вроде про SQL-запросы речь шла?
Речь наоборот шла про то, чтобы юзверю не надо было учить SQL, как не надо его учить для построения приложений в MS Access.
А вызов "надомного программиста" всегда будет стоить чудовищно дорого.
Расценки вызовов 1С поддержки тому подтверждение.
S>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
От твоего директора, который полез программировать и не справился.
V>>Это та самая автоматизация рутины.
V>>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
S>Так дело же не в том, что «мышкой нащёлкать».
Для no-code — именно в этом.
S>Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее.
Нельзя.
Для юзверя это будет что-то вроде программирования на ассемблере.
S>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
И что теперь?
Так и продолжать забивать гвозди микроскопом?
А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
FOREIGN KEY (CustomerId) REFERENCES Customers (Id)вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
CustomerId➔Customers.Id
Меня за мои почти 30 лет карьеры плоский текст задолбал, если честно.
Воз и ныне там, с чего начинал когда-то — так всё и есть до сих пор.
А вот это г-но мамонта полувековой давности в скриптах SQL — банальная роспись индустрии в недееспособности.
No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.
Их можно будет подменять, не трогая "верхней" функциональности.
А сейчас всё пляшет от языка и только от него.
И в самих языках наблюдается отчётливый кризис жанра. ))
"Новейшие" языки пытаются изобрести то, что изобретено еще в 70-80-90-е.
Всё вместе, в некотором смысле, деградация.
Плохая интероперабельность.
Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
Позорище это, а не достижение.
Сдаётся мне, рано или поздно OLE переизобретут. ))
S>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?
Разумеется!
В таблице Менделеева есть естественный ключ {атомный-номер}.
В таблице изотопов будет составной ключ {атомный-номер, массовое-число}, при этом поле "атомный-номер" мы зададим еще внешним ключом к таблице Менделеева, а значит по нему автоматически будет создан индекс.
S>Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей?
1. От незнания.
2. От ничтожного размера хранимых данных.
S>Или в почтовом клиенте/органайзере они есть?
Почти всегда.
S>Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля.
Правильно спросили.
Перевожу вопрос на русский язык:
"Вы, дядя, если не дурак, то уж точно заблудились, бо в реляционной БД имеет смысл хранить только реляционные данные. В противном случае воспользуйтесь, пожалуйста, другим видом хранилища".
Дело в том, что реляционные хранилища — они очень дорогие, неэффективные и т.д.
Это при оценке их эффективности снизу.
Они делают кучу на первый взгляд ненужных телодвижений при простой записи и даже, блин, ты будешь ржать — куча каких-то телодвижений даже для простого, блин, чтения.
Кароч, всё через анус, всё не как у нормальных людей.
Но когда у нас есть связанные данные на гига- и терабайты, когда эффективность оцениваем сверху (гигабайты данных по результатам работы оптового предприятия мы получали уже в 90-х), то ничего лучше реляционных хранилищ человечество пока не придумало.
S>Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
Ладно, сорри.
Твой стиль напоминает сочинение из разряда "как я провёл лето".
================
Такое складывается ощущение, что ваше поколение не то что не стремится поддерживать цену своим словам, а просто не в курсе про существование такого критерия оценки личности.
— Говори по существу.
— Любые подробности должны тем или иным образом относится к делу. Растекаться мыслью по дереву тоже надо уметь.
— Не злоупотребляй оценочными суждениями, а лучше вообще от них отказаться в технических рассуждениях.
Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?
Re[8]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Shtole, Вы писали:
V>>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
S>Например, через формульные колонки и колонки-ссылки.
Как это выглядит в GUI?
S>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))
Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.
Затем создай визардом новый запрос, просто накидай поля с двух связанных таблиц, убедись в режиме конструктора, что таблицы связаны по внешнему ключу как ты и указал в схеме данных до этого.
V>>Вызов тыжпрограммиста 1С обходится слишком дорого.
S>Так вроде про SQL-запросы речь шла?
Речь наоборот шла про то, чтобы юзверю не надо было учить SQL, как не надо его учить для построения приложений в MS Access.
А вызов "надомного программиста" всегда будет стоить чудовищно дорого.
Расценки вызовов 1С поддержки тому подтверждение.
S>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
От твоего директора, который полез программировать и не справился.
V>>Это та самая автоматизация рутины.
V>>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
S>Так дело же не в том, что «мышкой нащёлкать».
Для no-code — именно в этом.
S>Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее.
Нельзя.
Для юзверя это будет что-то вроде программирования на ассемблере.
S>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
И что теперь?
Так и продолжать забивать гвозди микроскопом?
А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
CustomerId➔Customers.Id
Меня за мои почти 30 лет карьеры плоский текст задолбал, если честно.
Воз и ныне там, с чего начинал когда-то — так всё и есть до сих пор.
А вот это г-но мамонта полувековой давности в скриптах SQL — банальная роспись индустрии в недееспособности.
No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.
Их можно будет подменять, не трогая "верхней" функциональности.
А сейчас всё пляшет от языка и только от него.
И в самих языках наблюдается отчётливый кризис жанра. ))
"Новейшие" языки пытаются изобрести то, что изобретено еще в 70-80-90-е.
Всё вместе, в некотором смысле, деградация.
Плохая интероперабельность.
Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
Позорище это, а не достижение.
Сдаётся мне, рано или поздно OLE переизобретут. ))
S>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?
Разумеется!
В таблице Менделеева есть естественный ключ {атомный-номер}.
В таблице изотопов будет составной ключ {атомный-номер, массовое-число}, при этом поле "атомный-номер" мы зададим еще внешним ключом к таблице Менделеева, а значит по нему автоматически будет создан индекс.
S>Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей?
1. От незнания.
2. От ничтожного размера хранимых данных.
S>Или в почтовом клиенте/органайзере они есть?
Почти всегда.
S>Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля.
Правильно спросили.
Перевожу вопрос на русский язык:
"Вы, дядя, если не дурак, то уж точно заблудились, бо в реляционной БД имеет смысл хранить только реляционные данные. В противном случае воспользуйтесь, пожалуйста, другим видом хранилища".
Дело в том, что реляционные хранилища — они очень дорогие, неэффективные и т.д.
Это при оценке их эффективности снизу.
Они делают кучу на первый взгляд ненужных телодвижений при простой записи и даже, блин, ты будешь ржать — куча каких-то телодвижений даже для простого, блин, чтения.
Кароч, всё через анус, всё не как у нормальных людей.
Но когда у нас есть связанные данные на гига- и терабайты, когда эффективность оцениваем сверху (гигабайты данных по результатам работы оптового предприятия мы получали уже в 90-х), то ничего лучше реляционных хранилищ человечество пока не придумало.
S>Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
Ладно, сорри.
Твой стиль напоминает сочинение из разряда "как я провёл лето".
================
Такое складывается ощущение, что ваше поколение не то что не стремится поддерживать цену своим словам, а просто не в курсе про существование такого критерия оценки личности.
— Говори по существу.
— Любые подробности должны тем или иным образом относится к делу. Растекаться мыслью по древу тоже надо уметь.
— Не злоупотребляй оценочными суждениями, а лучше вообще от них отказаться в технических рассуждениях.
Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?
V>>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
S>Например, через формульные колонки и колонки-ссылки.
Как это выглядит в GUI?
S>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))
Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.
Затем создай визардом новый запрос, просто накидай поля с двух связанных таблиц, убедись в режиме конструктора, что таблицы связаны по внешнему ключу как ты и указал в схеме данных до этого.
V>>Вызов тыжпрограммиста 1С обходится слишком дорого.
S>Так вроде про SQL-запросы речь шла?
Речь наоборот шла про то, чтобы юзверю не надо было учить SQL, как не надо его учить для построения приложений в MS Access.
А вызов "надомного программиста" всегда будет стоить чудовищно дорого.
Расценки вызовов 1С поддержки тому подтверждение.
S>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
От твоего директора, который полез программировать и не справился.
V>>Это та самая автоматизация рутины.
V>>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
S>Так дело же не в том, что «мышкой нащёлкать».
Для no-code — именно в этом.
S>Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее.
Нельзя.
Для юзверя это будет что-то вроде программирования на ассемблере.
S>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
И что теперь?
Так и продолжать забивать гвозди микроскопом?
А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
FOREIGN KEY (CustomerId) REFERENCES Customers (Id)вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
CustomerId➔Customers.Id
Меня за мои почти 30 лет карьеры плоский текст задолбал, если честно.
Воз и ныне там, с чего начинал когда-то — так всё и есть до сих пор.
А вот это г-но мамонта полувековой давности в скриптах SQL — банальная роспись индустрии в недееспособности.
No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.
Их можно будет подменять, не трогая "верхней" функциональности.
А сейчас всё пляшет от языка и только от него.
И в самих языках наблюдается отчётливый кризис жанра. ))
"Новейшие" языки пытаются изобрести то, что изобретено еще в 70-80-90-е.
Всё вместе, в некотором смысле, деградация.
Плохая интероперабельность.
Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
Позорище это, а не достижение.
Сдаётся мне, рано или поздно OLE переизобретут. ))
S>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?
Разумеется!
В таблице Менделеева есть естественный ключ {атомный-номер}.
В таблице изотопов будет составной ключ {атомный-номер, массовое-число}, при этом поле "атомный-номер" мы зададим еще внешним ключом к таблице Менделеева, а значит по нему автоматически будет создан индекс.
S>Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей?
1. От незнания.
2. От ничтожного размера хранимых данных.
S>Или в почтовом клиенте/органайзере они есть?
Почти всегда.
S>Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля.
Правильно спросили.
Перевожу вопрос на русский язык:
"Вы, дядя, если не дурак, то уж точно заблудились, бо в реляционной БД имеет смысл хранить только реляционные данные. В противном случае воспользуйтесь, пожалуйста, другим видом хранилища".
Дело в том, что реляционные хранилища — они очень дорогие, неэффективные и т.д.
Это при оценке их эффективности снизу.
Они делают кучу на первый взгляд ненужных телодвижений при простой записи и даже, блин, ты будешь ржать — куча каких-то телодвижений даже для простого, блин, чтения.
Кароч, всё через анус, всё не как у нормальных людей.
Но когда у нас есть связанные данные на гига- и терабайты, когда эффективность оцениваем сверху (гигабайты данных по результатам работы оптового предприятия мы получали уже в 90-х), то ничего лучше реляционных хранилищ человечество пока не придумало.
S>Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
Ладно, сорри.
Твой стиль напоминает сочинение из разряда "как я провёл лето".
================
Такое складывается ощущение, что ваше поколение не то что не стремится поддерживать цену своим словам, а просто не в курсе про существование такого критерия оценки личности.
— Говори по существу.
— Любые подробности должны тем или иным образом относится к делу. Растекаться мыслью по древу тоже надо уметь.
— Не злоупотребляй оценочными суждениями, а лучше вообще от них отказаться в технических рассуждениях.
Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?