Microsoft PowerApps

PowerApps — это служба для создания и использования пользовательских бизнес-приложений. Она подключается к вашим данным и может работать как в Интернете, так и при помощи мобильной связи. С этой службой вы сэкономите время и деньги, которые обычно тратите на разработку специального ПО.
https://powerapps.microsoft.com/ru-ru/blog/

Как это всё выглядит
https://www.youtube.com/watch?v=TUxEQKYv0oU
https://www.youtube.com/watch?v=8rtVTIikXyU

Интеграция со всякими там экселями зачёт. Вместо кода бизнес-правила, это что-то типа высоко-высокоуровневого языка программирования

Что думаете?

(126)
1С: Предриятие. Уродство языка и намеренное избегание в нем абстракций (типов переменных, коллекций и т.д.) обусловлено опять таки первоначальным намерением переложить работу по программированию на бухгалтеров. Бухгалтеры на предложение сделать все самим дружно крутят пальцами у виска. Результатом является жуткий дефицит грамотных 1С-программистов (не всякий на это чудо пойдет), при обилии мальчиков-по-вызову, которых все потом матерят.

О да

А судя по http://catalog.mista.ru/journal/news/biznes/google-obyavil-o-masshtabnoy-reorganizatsii-v-poiskakh-novykh-dokhodov_1058146/
тяжелые времена ждут

(125) а чего мелкософтовцы тогда буквально в этом месяце преподносят сие творение как инновацию?

https://powerapps.microsoft.com/en-us/blog/powerapps-for-pros-develop-faster-with-low-code/

(127) https://powerapps.microsoft.com/ru-ru/blog/virgin-atlantic-drives-agile-wins-for-mobile-workforce-with-the-power-platform/

(131) И все? Автоматизация ИГИЛЕ?

(132) да х.з. Я же не слежу за ними

Ну как то не впечатляет.
Где эти самые закратили затраты в 3е и у генерального лысина волосами покрылась?)

(126) отличная статья!

текст статьи небольшой, так что можно ее перепостить полностью

ниже текст из ссылки поста (126)
---
Кухарка и государство
Чулан
Светлая мысль, что «любая кухарка может научиться управлять государством» (В.И.Ленин) запала головы бизнесменов и разработчиков еще на заре автоматизации и с тех пор не покидала их ни на минуту. В переводе на язык IT, она стала звучать примерно так «мы дадим пользователю удобные средства, а он пусть сам все настроит и сделает». Все ведь просто! Пользователь в своей области (выпекание тортов, выдача кредитов, проводка по счетам, ...) понимает? Понимает. Вот пусть сам там и возится. А нам не досуг вникать, дадим инструменты и вперед, главное чтоб платил.

Эту гениальную в своей простоте идею, пытались реализовать неоднократно. Яркие примеры:

* Язык SQL. Наверно все знают, что произошел он от SEQUEL (Structured English Query Language) и предназначался для написания запросов конечными пользователями — отсюда его столь неординарный синтаксис. Программистов, которые вынуждены им пользоваться ныне, устроил бы куда более современный и формальный язык, но, увы — стандарты, совместимость…
* COBOL. Комментировать нечего. Слава Богу нашу страну почти не задело, да и на Западе 2000 год эту страницу истории закрыл (почти).
* EXCEL (и т.п.). Казалось бы — явно успешный продукт. Это до тех пор, пока сложность логики и объем таблиц не переходят какой-то предел (довольно невысокий) и не встает необходимость переноса всего «контента» в более структурированный вид (БД). Вот тут взявшийся и понимает почем фунт лиха и чего может наворотить «талантливый менеджер, экономящий деньги фирмы на дармоедах-автоматизаторах»! А если тот еще овладел VBA… И кронная фраза «Все ведь работало!»…
* 1С: Предриятие. Уродство языка и намеренное избегание в нем абстракций (типов переменных, коллекций и т.д.) обусловлено опять таки первоначальным намерением переложить работу по программированию на бухгалтеров. Бухгалтеры на предложение сделать все самим дружно крутят пальцами у виска. Результатом является жуткий дефицит грамотных 1С-программистов (не всякий на это чудо пойдет), при обилии мальчиков-по-вызову, которых все потом матерят.

И список еще далеко не закрыт.

Еще одна вариация светлой мысли: посадим девочку (мальчика, Петровича, Маргариту Семеновну), дадим ей книжку по VisualBasic-у, читать чай умеет — вот и пусть программирует, «не боги горшки обжигают». Про богов и горшки может и верно, но вот знать правила игры в шахматы и играть в шахматы, хотя бы на уровне 3го разряда — вещи совершенно разные и с этим почему-то никто и не спорит.

В чем же проблема? Почему простая и хорошая (казалось бы) идея не срабатывает?
Проблема в «кухарке», точнее в уровне ее мышления. Утрировано: кухарка оперирует понятиями типа «1 ложка на кастрюлю», «по-вкусу», «до готовности», ее мышление конкретно и субъективно, при этом результата она достигает не плохого, т.к. задача того и требует. Заставлять ее подниматься на высокий уровень абстракции и решать задачу «в общем виде» — антигуманно. Если не верите, попросите свою маму (жену, бабушку, тещу) записать какой-нибудь фамильный рецепт с точным указанием всех весов, объемов и пропорций, предусмотрев случаи «нет соли (лука, перца, огня, воды, света)», «времени — 10 минут», «одновременно готовить еще 5 блюд», «на 10, 20, 120, 20000 человек», «экономить по-максимуму» и другие, какие придут в голову (хм… тещу, пожалуй, не надо — может не простить глумления). Но почему-то стремление нагрузить аналогичным творчеством бухгалтера, оператора или клерка кажется многим весьма неплохой мыслью.

Кухарку можно научить (при наличии способностей!) и государством управлять, но для этого нужен не один год, не одна книжка и, неисключено, горы перебитой посуды и испорченных блюд. А главное: кухаркой к тому времени она быть уже перестанет. Так стоит ли браться?

Оригинал

UPD: Фраза «любая кухарка может научиться управлять государством» в работах Ленина не встречается, хотя у него есть близкие по смыслу высказывания.

(126) Да все правильно, 10 лет прошло еще а ничего не изменилось

(114) Это очень вредные для организации работники. Фактически, работа организации ставится в зависимость от конкретного человека. Он умирает или уходит - и все, учет развален.

(118) ERP с такими ограничениями? Да там даже месяц не закроется.

(138) Как это не странно, но ты прав

(138) +1
Я в такой ситуации был, и полтора года переписывали в битфинанс пару десятков эксель и аксес файлов с огромными vba-скриптами, которые женщина-экономист в начале 2000х наваяла и со всем этим очень успешно все работало до 2015 года... начали после того как контору продали американцам и они сделали аудит ит подсистемы и прифигели с того что огромная часть критических бизнеспроцессов буквально на неё завязано

(136) статья красивая, эмоциональная, но... далека от объективности. Все современные авторы в один голос кричат, что хороший код это самодокументирующийся код, который читается "как книга". Причем принцип этот наметился отнюдь не сегодня, а наверно с полвека назад, когда с GOTO перешли на процедуры/функции. Языки программирования с высоким уровнем абстракции появились для того, чтобы разработчик с этими ЯП мыслил прежде всего терминами автоматизируемой предметной области, а не сосредотачивался на технических тонкостях реализации. Автор статьи видимо оленей не покормил, поэтому и написал такую ерунду. За языками программирования, близкими к естественным языкам, будущее.

(136) > Заставлять ее подниматься на высокий уровень абстракции и решать задачу «в общем виде» — антигуманно.

Но ведь это касается и нас с вами. «Кто виноват?» и «Что делать?» – вечные русские вопросы. Мы тут ругаем 1С (фирму и программы), технических 1С-программистов, работодателей и все что вокруг этого. Но как всегда это только верхушка айсберга, остальное наш мозг не видит. А подобные проблемы, как правило, имеют источник уровнем выше. В данном случае, это организация общественной системы и государства на ее основе. Слава Богу, когда речь заходит о военных «игрушках», типа «Авангард», «Посейдон», «Циркон», «Сармат», «Пересвет» и т.д., подобных проблем вроде не возникает. Над созданием этих «игрушек» работают сотни и тысячи предприятий, синхронно и очень эффективно. Все программы пишутся как надо, организовывается все по высшему разряду, в результате чего получается продукт мирового качества, конкурентов которому не будет еще многие годы. Даже исключения (вроде аварии с Суперджетом) лишь доказывают правило: «Там, где русская Система работает всерьез, все конкуренты отдыхают». Соответственно, там где «не получается», русская Система не работает либо работает не на полную мощность, в силу каких-либо политических ограничений.

Пока «1С»  будет сам по себе, законотворчество само по себе, образование, воспитание, экономика, политика и т.д. и т.п. сами по себе, диссонанс в работе государственной и общественной системы будет неизбежен.

Соответственно, каждый в этой общей какофонии ищет свою нишу. Кто-то находит, кто-то нет, а кто-то в вечном процессе поиска. Мир «1С» это очень хорошо демонстрирует :) .

Короче говоря, «кто хочет – ищет возможности, а кто не хочет – причины».

(141) Нормальная статья.
В одно время умы бредило - программировать может любой.
Это вылилось в то что мы видим.
По тому коду, который я вижу в гихабе - наоборот уход от естественных языков. Количество различных символов в коде поражает.
Первое что попалось под руку https://github.com/microsoft/calculator/blob/master/src/Calculator/Controls/CalculationResultAutomationPeer.cpp и это еще простенько.
Наоборот, языки программирования отходят от естественных языков, чуть ли не в символьную сторону.
И документируется не сам код, а его описание\тесты.

(141) >За языками программирования, близкими к естественным языкам, будущее.

Хаха. Ха.

Нет, будущее за простыми, лаконичными и быстро изучаемыми языками.
Удобными в применении, с минимальным кодом для написания, который тем не менее остается понятным любому другому изучившему язык.

И да будут стандарты на синтаксис языков (по их классам-назначению), различаться будут только функционал и реализации.

(144) Вово

(141) А теперь возьми и покажи мне листинг прикладного решения на основе продукта, который в этой веке обсуждается

(143) Ну если конечно название переменных ЯПамять, ЯДиспечер это переход к реальным языкам, то я даже не знаю что на это ответить

Говорить о "близости к естественным языкам" ЯП примерно как говорить о близости инженерно-конструкторских чертежей и документации к "наброскам/рисункам от руки".

Типа любой продвинутый пользователь сможет конструировать свои механизмы и приборы.

(143) программировать можно научить даже обезьяну, это не сложный навык. А писать качественный код могут немногие. Говнокодерство обходится предприятиям дорого, ибо порождает колоссальные косвенные расходы. Поэтому закономерно стремление создавать языки программирования, способные противостоять говнокодерству. Пока что, правда, говнокодеры не сдаются, но и борьба ещё не закончена.

(148) Отличный кстати пример.
Я когда на даче дом проектировал, то скачал sketchup
Чо удобно. 3д мышкой.
Сделал планировку, 3д модель, чертежи и отправил конторе, которая строить должна.
Там более 100 замечаний было, причем некоторые могли к обрушению привести
В итоге инженер переделал, максимально сохранив мою идею.

(149) Нельзя. Она или перестанет быть обезьяной или ничему не научится.

(151)+ Точнее может научиться имитировать деятельность по программированию, выдавая чужие куски кода кое как слепленные за свои https://1cers.ru/index.php?user_id=107923

(144) а чем близость к естественному языку мешает лаконичности и быстроте изучения?
(148) вот те раз. Так значит изобретатели объектно-ориентированного программирования, позволившего "излагать" сложные программы в виде абстракций по типу объектов внешнего мира, были дураками?

(153) скажем так, ООП это было очевидное развитие на тот момент.
Но оно избыточно и сложно, когда начинается ООП ради ООП.
То же функциональное программирование сейчас 2е рождение проходит.

(153) > а чем близость к естественному языку мешает лаконичности и быстроте изучения?
Естественные языки не лаконичны, не логичны и излишне перегружены в т.ч. исключениями

>...были дураками?
Абстракции высших порядков это очень сложная штука как и умение ими мыслить. И ООП это очень далеко от естественности.

(154) Наследование выкинули но более поздно придуманные интерфейсы оставили, причем довели идею до абстрактности, когда есть пустой интерфейс который у любого объекта, хотя и не рекомендуют применять это.

Имхо сейчас развиваются две тенденции. С одной стороны со стороны классического программирования идёт процесс упрощения/ускорения написания программ за счёт упрощения ЯП, появления удобных фреймворков, библиотек и т.д, с другой стороны появляются полуготовые конфигурируемые продвинутыми пользователями решения которые позволяют решать задачи без программирования.
Где то в какой то момент времени эти две тенденции могут пересечься в виде появления крутых инструментов доступных как традиционным программерам так и продвинутым юзерам. В качестве таких примеров уже сейчас могу назвать UI Rpa
https://m.youtube.com/watch?v=39Yz0cOp-zs

(156) + В примере ниже пустой интерфейс с приведением к нужному типу

user, ok := s.Attr("user").(User)
if ok {
  fmt.Println("Получили User " + user.EMail)
}


Перед этим делается
e.Session().SetAttr("user", user)
И туда можно любого типа засунуть, гениально по сути

(155) "Естественные языки не лаконичны, не логичны и излишне перегружены в т.ч. исключениями"

Странно это слышать от человека, пишущего на 1С.

"И ООП это очень далеко от естественности"

Как раз ООП это стремление к естественности.

ЗеленаяЛягушка = New Лягушка;
Лягушка.Прыг();
Лягушка.Квак();

(159) И что тут естественного? Кроме применения удобных слов для пишущего, причем из удобного ему языка.

Ты легко прочитаешь?
greenFrog = New Frog();
greenFrog.jump();
greenFrog.croak();

А если тоже самое будет на китайском или суахили?

(159) Чтение из строки в Java красивым ООП

InputStream inputStream = System.in;
Reader inputStreamReader = new InputStreamReader(inputStream);
BufferedReader bufferedReader = new BufferedReader(inputStreamReader);
String name = bufferedReader.readLine(); //читаем строку с клавиатуры

(161) из консоли

Эти прыг скак дальше учебника не идут.
Кровавый набор текста и море сахара, что бы текста набирать было меньше.

(161) ыыы

package main
import (
    "fmt"
    "os"
)

func main() {
    var name string
    fmt.Print("Введите имя: ")
    fmt.Scan(&name)
    fmt.Println(name)
}

(164)+ Или так с указанием стандартного потока
package main
import (
    "fmt"
    "os"
)

func main() {
    var name string
    fmt.Print("Введите имя: ")
    fmt.Fscan(os.Stdin, &name)
    
    fmt.Println(name)
}

(160) все пишут на английском. Ну мы тут ещё пытаемся писать на славянском.
(163) а это смотря как код писать. Есть множество принципов "тру-программирования", позволяющих повышать читабельность кода и снижать его семантическую сложность.

(166) о да.
Только зачем сотни, тысячи, а то и сотни тысяч разработчиков в ИТ компаниях? Если все так просто?
На сайт с нуля по современным технологиям по хорошему надо под 10 человек

(167) Если сайт реальный то да минимум 10 человек.
В одиночку все никак не выйдет, или будет убого как у меня в прототипе моего сервиса.
Но программистов пары хватит, один fronend и второй backend, дальше разные дизайнеры и прочие.

(168)+ Причем html/css верстальщиков несколько надо чтобы дизайн на код фронта натягивать ))

(167) так и сайтов в природе не пять штук, оттого и много программистов

(170) сайт как пример.
В остальных областях то же самое

(170) Проблема в том что создание сайтов свели (точнее пытались некоторые) к "как построить замок своими руками"

(171) программистов было бы ещё больше, если бы в своё время не слезли с низкоуровневых языков программирования на всё более и более близкие к естественному языку высокоуровневые ЯП. Давай снова глянем на SQL, уже давно ставший стандартом для всех СУБД. Автор той статьи утверждает, якобы это попытка посадить кухарок за СУБД. Но это чушь и бред. SQL стал стандартом потому, что он оказался удобен, а не из-за заговоров злых манагеров.

(173) скл стал стандартом потому что возникла потребность, а ничего другого без доработки напильником или написания с нуля не было.

(173) SQL стал стандартом потому что альтернатив вменяемых не было.
И была мощная поддержка (практически лобби) https://ru.wikipedia.org/wiki/Реляционная_модель_данных со стороны известных математиков/физиков и прочих кто теорию для первых компов делал и софт писал.

Массовая потребность точнее

(161) Отличный пример того что современные языки позволяют работать в несколько строчек как на низком уровне с байтами так и на высоком.
То же чтение из консоли:

java.util.Scanner scanner = new Scanner(System.in);
String line = scanner.nextLine();

И ведь чертовщина в том что меняя System.in читаем хоть из файла, хоть из сети, хоть из ком порта.
Лаконично и мощно.

(174) а может всё-таки SQL удобен, оттого и так хорошо прижился?

"SQL стал стандартом потому что альтернатив вменяемых не было"

SQL скоро отметит пятидесятилетие. Как так получилось, что за полвека не нашлось альтернатив скулю? Мне видится, что альтернатив ему никто и не искал, ибо он удобен и лаконичен. Также как не ищут альтернативу таблице Менделеева, хоть она и изобретена в древнелохматые времена. Неудобен SQL разве что автору той статьи, но ему наверно не только SQL мешает танцевать.

(178) Ты последнюю полную спецификацию SQL читал?
Как думаешь зачем изобрели отдельные несовместимые T-SQL и PL/SQL с подвариантами?

SQL хорош только на простых базовых запросах, выборка.
Даже синтаксис для вставки и обновления записей уже идиотский и натянут на верблюда.

Если же сложность чуть возрастает то читаемость стремится к 0.

Это нихрена не читается и неудобно:
INSERT INTO table_name (column1, column2, column3, ...)
VALUES (value1, value2, value3, ...);

Намного лучше:
table_name add column1=value1, column2=value2, column3=value3, ...

(180) Та ладно. А как ты в такой синтаксис подставишь вставку из результата другого запроса.
Или для вставки результата из select-а будет второй синтаксис. А потом еще какие случаи третий сочиним?

(180) не вижу никакого преимущество предложенного тобой варианта над INSERT. К тому же ключевое слово INTO не обязательное.

(181) Умный блин ))
Да с этим в моей конструкции есть некий недостаток, но оно же и преимущество ибо можно именами полей оперировать

sql1 = table_name1 select ...
table_name2 add column1=sql1.value1, column2=sql1.value2, column3=sql1.value3

(178) по той же причине, по которой спустя столетие после мирового перехода на метрическую систему, имперская до сих пор используется, например бытовое трубное хозяйство до сих пор в дюймах.
Слишком дорого это менять

(183)+ Хотя наверно лучше иначе
sql1 = table_name1 select ...
table_name2 add sql1 column1=value1, column2=value2, column3=value3
где value1, value2, value3 это имена полей в sql1

(185) открой любой технический скрипт, да тот же замер ожиданий - глаза течь начинают

(159) А теперь сделай кентавра.

(187) Наследоваться от лягушки и перекрыть квак?

(188) Так хоть наследуй, хоть нет, а реализацию все равно прорабатывать :) Причем именно на реализацию уйдет 90+% времени.

(181) это наверняка легко и изящно делается в вим

(41) Да, банкроство микрософта близко как никогда:

В первые часы после открытия торгов 25 апреля 2019 года на бирже NASDAQ цена акций компании Microsoft ненадолго повысилась до $131.37 (максимум), в результате чего рыночная капитализация Microsoft превзошла отметку в 1 триллион долларов.

Капитализация на данный момент: Гугл - 810 626 848 147, Амазон - 930 497 210 004, Майкрософт - 974 174 042 170.

В компании Microsoft в целом доход за квартал составил $30,6 млрд. (+14%). Операционная прибыль выросла на 25% до $10,3 млрд., чистая прибыль составила $8,8 млрд. (+19%).

(191) на самом деле ниочем не говорит, нокиа стоила огромных денег, sun стоила огромных денег, моторола стоила огромных денег
гиганты как появляются, так и падают, вопрос лишь в адекватности менеджмента и как показывает практика - вечных контор не бывает за очень редким исключением типа сименса и ibm

У гугла например огромная капитализация, но при этом они уже очень давно не могут придумать ничего нового, аналогично эппл у которого уже проблемы с продажами

микрософт почуял что жареным пахнет уже давно...тогда и началась свисопляска с Win8/rt ...временно им помогло...но тенденция заката десктопов продолжается, сумеют ли они удержатся а azure...

(141) (144)
Прочитал Ваш обмен репликами и одного только не понял. Может кто-нибудь из Вас мне пояснит? На хрена близость к естественному языку языка программирования искусственному интеллекту грубо говоря, а в современной технологии нейросети. Она что не может какой-то язык программирования выучить из тех которые студент попросит её выучить чтобы курсач ему написать?
https://www.popmech.ru/technologies/news-480252-sozdany-neveroyatno-effektivnye-neyroseti-mashinnoe-obuchenie/

Вот здесь на видео достойный учёный муж Пеереслегин рассуждает насчет того что мы из субъектов права неуклонно превращаемся в объекты права в отношении которых искусственные нейронные сети договариваются между собой. Очень рекомендую послушать.

https://www.youtube.com/watch?v=8Bona2OfD8o

(193) Хрень пока эти ИИ/нейросети/ML, без программиста который данные подготовит с очисткой, признаки укажет и т.д. ничего не могут.

А вот это делать лучше на удобном языке, пока для этого или питон или R чаще всего.
Причем питон по той же причине что в свое время sql ибо математическая библиотека крутая написана и де факто стандартом становится.

Так что курсачи студентам придется по старинке или самим писать или заказывать за денежку.

(194) Ты реально веришь этим грантоделителям?

(193) А курсач после этого проверку на антиплагиат пройдет? Научились ли нейросети создавать что-то действительно новое, а не только комбинировать то, что уже было создано?

(194) В ближайшем обозримом будущем лет так дцать никакого сильного ИИ в реальности не будет.
Банальная физика - плотности схем пока недостаточно.

Точнее можно и при текущей плотности электронных схем но слишком он тормозной будет.

(197) Ну буквы те же самые и точки )) Просто особая комбинация

(192) Большие компании очень медлительные. Их губит бюрократия и полное безразличие персонала к происходящему. А если туда еще деньги инвесторов пришли, то все. Чтобы доказать, что направление будет перспективным нужно все круги ада пройти.
у 1С тоже самое. Вот висит статья http://catalog.mista.ru/public/695523/ с 17 года. Если скачать конвертацию 3.0 и попытаться ей воспользоваться то она будет неработоспособна. В маленькой компании как бы сделали. Почему у нас официальный продукт неработоспособен и бросили бы все силы на исправление. А в большой, пока зафиксируют проблему, пока она пройдет все стадии визирования, потом подключаться тестировщики, разработчики и их руководители. Потом кто-то уйдет в отпуск, потом еще кто-то уволится. И все растягивается на бесконечное тягомотину.

(200) Медлительные это слабо сказано, пока реальная жопа не подойдет ближе совсем не шевелятся или что хуже не туда двигаются.

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

(201) Не полная хрень, а политика

(202) Там еще кулуарные заговоры похлеще всех "Игр престолов".

(200) Опенсорснутые продукты зачастую более качественные и более оперативно реагируют на клиентские запросы. Хотя вроде бы все должно было бы быть наоборот. Дело не в размере компании а в ее идеологии и вовлеченности команды. В крупных корпоративных компаниях с энтузиазмом команды как то тяжело, вот и получается дитя (продукт) без присмотра.

(204) опен сорс это далеко не всегда команды энтузмастов за лайки.
Там полным полно и инвесторских проектов, которые пишут за огромные деньги огромные команды в тех же корпорациях.
OpenSource <> бесплатно

(192) Ржака. Аналитика 99lvl. У компании уверенный рост по всем направлениям включая десктоп (+9%), по azure рост вообще 73%, но местные аналитики "посмотрят, сумеет ли удержаться". Ну, смотрите, чо уж.

(179) "Как думаешь зачем изобрели отдельные несовместимые T-SQL и PL/SQL с подвариантами?"

Предлагаю рассматривать эту ситуацию иначе: в основе языков программирования двух топовых конкурирующих СУБД лежит всё тот же "дедушка" SQL. Видится мне, применяют его там не случайно, а из-за удобства.
Можно долго рассуждать по поводу неудобства и излишней громоздкости русского языка, только вот россияне к нему давно привыкли и ничего менять не хотят. Также и с SQL.

(185) снова не вижу никакого преимущества перед INSERT . К тому же часто INSERT используется для вставки нескольких явно указанных значений, тут твой синтаксис оказывается излишне громоздким. Сравни:

INSERT table_name (Фамилия, Имя, Отчество)
VALUES ('Иванов', 'Иван', 'Иванович')
VALUES ('Петров', 'Петр', 'Петрович')
VALUES ('Сидоров', 'Сидр', 'Сидорович')

как будет выглядеть твоя конструкция

table_name add Фамилия='Иванов', Имя='Иван', Отчество='Иванович'
table_name add Фамилия='Петров', Имя='Петр', Отчество='Петрович'
table_name add Фамилия='Сидоров', Имя='Сидр', Отчество='Сидорович'

Кстати, если наскучил SQL, можно посидеть на СУБД MongoDB. Там нет SQL. Поговаривают, что угрёбище конкретное, и сложные запросы там натурально вырвиглаз.

(208) Неа

table_name add Фамилия=('Иванов','Петров','Сидоров'), Имя=('Иван','Петр','Сидр'), Отчество=('Иванович','Петрович','Сидорович')

(210)+ Обрати внимание что у меня в разные поля можно вставлять данные выбрав их разными запросами, лишь бы кол-во записей в выборках совпадали.
Как это провернуть в классическом SQL легко хз, без кучи апдейтов или предварительного соединения таблиц.

(210) при большом количестве значений чревато ошибкой, плюс будет жутко неинформативно

(211) "Обрати внимание что у меня в разные поля можно вставлять данные выбрав их разными запросами, лишь бы кол-во записей в выборках совпадали"

А это вообще зло во плоти. Рукожоп порукожопит немного, потом придётся долго чесать репу, как на продуктовом складе оказалось "Видеокарта Radeon 10.36 кг" и что с этим делать

(211) Не совсем понятно что имеется ввиду под "Как это провернуть в классическом SQL легко хз", но вроде элементарно:

INSERT table_name (Фамилия, Имя, Отчество)
SELECT
  Фамилия
  , SELECT Имя FROM table2 WHERE table2.Фамилия = table1.Фамилия
  , SELECT Отчество FROM table3 WHERE table3.Фамилия = table1.Фамилия AND table3.Имя = (SELECT Имя FROM table2 WHERE table2.Фамилия = table1.Фамилия)
FROM
  table1

(0) Очередной "убийца" одноэски.

(0) 40$ на пользователя в месяц в облаке - в России не взлетит

А что сейчас с Ахаптой? Тоже была убийца.

(216) Аксапта прошла, потом был dymamics, сейчас вроде power! BI. ах  да постойте где он?

(216) живет
http://www.tadviser.ru/images/8/8f/Erp_pop_2017_2.png
http://www.tadviser.ru/index.php/ERP

(217) аксапта превратилась в Dynamics AX

(0) Специфика российского рынка в том что глобальным игрокам он в приоритете не нужен!
А реальный убийцы 1С быстро получают приставку 1С к названию продукта ;)
- 1C bitrix
- 1C moysklad
- 1C AmoCRM

"Убийца 1С" может родиться только в России. И чем больше 1С усложняет свои программы, тем быстрее.

А вопрос санкций тут рассматривался?!

(213) И вот говоришь этот изврат читается да? Поубивав бы придумщиков

(215) PowerApps есть в составе office365 business premium. Порядка 14$ в месяц

(218) офигенный график, учитывая что 95% отзывов об успешном внедрении программного продукта 1С сводится к отгрузке коробки.

(218) Ага, у Axapta был один фатальный недостаток :)

(0) Тут вот еще один убивца 1С. Походу пошла мода на всякие визуальные средства проектирования.

https://www.youtube.com/watch?v=6Dz9xXmJU0U

(224) Мне думается, что просто отгрузка - это плюс, а не минус с любых точек зрения (или нашелся такой клиент, для которого допил не нужен или продукт не нуждается в допиле).