Вопросы на собеседовании 1С программист

Попробовал тут у нейросетей спросить вопросы, неплохо:

  1. Объясните разницу между управляемыми и обычными блокировками в 1С:Предприятие 8.3.
  2. Как вы понимаете термины “реквизит”, “ресурс” и “бизнес-процесс” в контексте 1С:Предприятия?
  3. В чем разница между методами “НайтиПоСсылкам” и “ПолучитьОбъект” в 1С:Предприятии?
  4. Что такое “контекст безопасности” в 1С:Предприятии и как он влияет на работу системы?
  5. Какие основные отличия между платформами 1С:Предприятие 7.7 и 1С:Предприятие 8?
  6. Как работает механизм кеширования в 1С:Предприятии 8 и как его можно настроить?
  7. Как создать пользователя в конфигурации 1С:Управление торговлей и какие права доступа ему назначить?
  8. В чем отличие между запросами “Выбрать” и “Прочитать” в 1С:Предприятии?
  9. Что такое “сериализация” и “десериализация” объектов в 1С:Предприятие, и как они используются?
  10. В чем различие между объектами “Документ” и “Справочник” в 1С:Предприятие?
  11. Как работает система контроля доступа (RAC) в 1С:Предприятие и как она связана с ролевой моделью доступа?
  12. В чем особенность использования временных таблиц в языке запросов 1С:Предприятие по сравнению с другими СУБД?
  13. В чем разница между синхронными и асинхронными запросами в 1С?
  14. Как работают транзакции в 1С и как их можно управлять?
  15. В чем заключается процесс оптимизации запросов в 1С?
  16. Как осуществляется отладка кода в 1С Предприятии и какие инструменты для этого предусмотрены?

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

Чем процесс отличается от потока?

В предыдущем посте, я рассказал Вам о понятии процесса в ОС. Сегодня же, я изложу более подробно о потоке, его отличии от процесса, а с помощью своих чудо-рук, ты сможешь создать консольный вариант Диспетчера задач (такой, немного убогий и без функции конечно…ну все-таки).

Первое, что надо усвоить — процесс состоит хотя бы из одного потока. В ОС каждому процессу соответствует адресное пространство и одиночный управляющий поток. Фактически это и определяет процесс.

С одной стороны, процесс можно рассматривать как способ объединения родственных ресурсов в одну группу. У процесса есть адресное пространство, содержащее текст программы и данные, а также другие ресурсы. Ресурсами являются открытые файлы, дочерние процессы, необработанные аварийные сообщения, обработчики сигналов, учетная информация и многое другое. Гораздо проще управлять ресурсами, объединив их в форме процесса.

С другой стороны, процесс можно рассматривать как поток исполняемых команд или просто поток. У потока есть счетчик команд, отслеживающий порядок выполнения действий. У него есть регистры, в которых хранятся текущие переменные. У него есть стек, содержащий протокол выполнения процесса, где на каждую процедуру, вызванную, но еще не вернувшуюся, отведен отдельный фрейм. Хотя поток должен исполняться внутри процесса, следует различать концепции потока и процесса. Процессы используются для группирования ресурсов, а потоки являются объектами, поочередно исполняющимися на центральном процессоре.

Концепция потоков добавляет к модели процесса возможность одновременного выполнения в одной и той же среде процесса нескольких программ, в достаточной степени независимых. Несколько потоков, работающих параллельно в одном процессе, аналогичны нескольким процессам, идущим параллельно на одном компьютере. В первом случае потоки разделяют адресное пространство, открытые файлы и другие ресурсы. Во втором случае процессы совместно пользуются физической памятью, дисками, принтерами и другими ресурсами. Потоки обладают некоторыми свойствами процессов, поэтому их иногда называют упрощенными процессами. Термин многопоточность также используется для описания использования нескольких потоков в одном процессе.

Любой поток состоит из двух компонентов:

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

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

  1. Поток (thread) определяет последовательность исполнения кода в процессе.
  2. Процесс ничего не исполняет, он просто служит контейнером потоков.
  3. Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах.
  4. Потоки могут исполнять один и тот же код и манипулировать одними и теми же данными, а также совместно использовать описатели объектов ядра, поскольку таблица описателей создается не в отдельных потоках, а в процессах.
  5. Так как потоки расходуют существенно меньше ресурсов, чем процессы, старайтесь решать свои задачи за счет использования дополнительных потоков и избегайте создания новых процессов(но подходите к этому с умом).

Ссылка в тему: Основы многопоточного программирования на CSharp: albahari.com/threading/index.html

А почитать еще теории? Рихтер и Таненбаум…

KISS принцип

KISS (акроним для «Keep it simple, stupid» — «Делай проще, тупица») — принцип проектирования, принятый в ВМС США в 1960[1][2].

Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности. Фраза ассоциировалась с авиаконструктором Кларенсом Джонсоном (1910—1990)[3]В 1970-х гг. широко использовался термин «KISS-принцип» (англ. KISS principle)[4]. Вариации на фразу включают «англ. Keep it Simple, Silly», «keep it short and simple», «keep it simple and straightforward»[5] и «keep it small and simple»[6].

ChatGPT — SQL запросы

Решил выложить свои опыты с чатджипити. Если кто не в теме — это ведь все строится на предсказании! появления! одного слова за другим:
чем right join отличается от left join в языке sql

В SQL существуют различные типы JOIN, которые позволяют объединять данные из разных таблиц. Один из таких типов JOIN — это LEFT JOIN и RIGHT JOIN.

LEFT JOIN возвращает все записи из левой таблицы и только те записи из правой таблицы, которые удовлетворяют условию JOIN. Если в правой таблице нет соответствующих записей, то возвращается значение NULL.

Пример использования LEFT JOIN:

SELECT *
FROM table1
LEFT JOIN table2
ON table1.id = table2.table1_id;

RIGHT JOIN, с другой стороны, возвращает все записи из правой таблицы и только те записи из левой таблицы, которые удовлетворяют условию JOIN. Если в левой таблице нет соответствующих записей, то возвращается значение NULL.

Пример использования RIGHT JOIN:

SELECT *
FROM table1
RIGHT JOIN table2
ON table1.id = table2.table1_id;

Таким образом, различие между LEFT JOIN и RIGHT JOIN заключается в том, что LEFT JOIN возвращает все записи из левой таблицы, а RIGHT JOIN — все записи из правой таблицы. В обоих случаях возвращаются только те записи из другой таблицы, которые удовлетворяют условию JOIN, а для отсутствующих записей используется значение NULL.

покажи разницу на примере

Рассмотрим две таблицы — Orders и Customers:

Таблица Orders:

OrderID CustomerID OrderDate
1 2 2022-01-01
2 3 2022-01-02
3 1 2022-01-03

Таблица Customers:

CustomerID CustomerName ContactName
1 Alfreds Maria
2 Ana Trujillo Ana
3 Antonio Moreno Antonio
4 Thomas Hardy Thomas

Теперь рассмотрим различия между LEFT JOIN и RIGHT JOIN в SQL.

Пример использования LEFT JOIN:

SELECT Customers.CustomerName, Orders.OrderDate
FROM Customers
LEFT JOIN Orders ON Customers.CustomerID = Orders.CustomerID;

Результат:

CustomerName OrderDate
Alfreds 2022-01-03
Ana Trujillo 2022-01-01
Antonio Moreno 2022-01-02
Thomas Hardy NULL

В данном случае мы используем LEFT JOIN для объединения таблиц Customers и Orders. В результате мы получаем все записи из таблицы Customers и только те записи из таблицы Orders, которые соответствуют условию соединения. Если в таблице Orders нет записей для определенного клиента, то возвращается значение NULL.

Пример использования RIGHT JOIN:

SELECT Customers.CustomerName, Orders.OrderDate
FROM Customers
RIGHT JOIN Orders ON Customers.CustomerID = Orders.CustomerID;

Результат:

CustomerName OrderDate
Ana Trujillo 2022-01-01
Antonio Moreno 2022-01-02
Alfreds 2022-01-03
NULL 2022-01-04

Здесь мы использовали RIGHT JOIN, чтобы объединить таблицы Customers и Orders. В результате мы получаем все записи из таблицы Orders и только те записи из таблицы Customers, которые соответствуют условию соединения. Если в таблице Customers нет записей для определенного заказа, то возвращается значение NULL.

что выведет в этом примере full join

Full join (или full outer join) объединяет все записи из двух таблиц, включая те, которые не имеют соответствующих записей в другой таблице. Если в таблице нет соответствующих записей, то для них будут использованы значения NULL.

Пример использования FULL JOIN:

SELECT Customers.CustomerName, Orders.OrderDate
FROM Customers
FULL JOIN Orders ON Customers.CustomerID = Orders.CustomerID;

Результат:

CustomerName OrderDate
Alfreds 2022-01-03
Ana Trujillo 2022-01-01
Antonio Moreno 2022-01-02
Thomas Hardy NULL
NULL 2022-01-04

Здесь мы используем FULL JOIN для объединения таблиц Customers и Orders. В результате мы получаем все записи из обеих таблиц, и те записи, которые соответствуют условию соединения. Если в таблице Customers нет записей для определенного заказа, то для них будет использовано значение NULL, и наоборот — если в таблице Orders нет записей для определенного клиента, то также будет использовано значение NULL.

покажи пример группировки в sql

Группировка в SQL используется для суммирования, подсчета или агрегации значений в таблице по определенным полям. Примером может служить таблица «Orders», содержащая информацию о заказах:

Таблица Orders:

OrderID CustomerID OrderDate Amount
1 2 2022-01-01 100
2 3 2022-01-02 200
3 1 2022-01-03 150
4 2 2022-01-04 75
5 3 2022-01-05 225
6 1 2022-01-06 50

Пример запроса на группировку по полю CustomerID и подсчету общей суммы Amount для каждого клиента:

SELECT CustomerID, SUM(Amount) AS TotalAmount
FROM Orders
GROUP BY CustomerID;

Результат:

CustomerID TotalAmount
1 200
2 175
3 425

Здесь мы используем функцию SUM() для суммирования значений поля Amount для каждого клиента. Затем мы используем ключевое слово GROUP BY для группировки по полю CustomerID. Результат показывает общую сумму заказов для каждого клиента.

покажи пример отбора и сортировки в sql

Отбор (фильтрация) и сортировка — это очень важные операции в SQL, которые позволяют выбирать и сортировать данные в таблицах. Для примера рассмотрим таблицу «Products», содержащую информацию о продуктах:

Таблица Products:

ProductID ProductName SupplierID CategoryID Price
1 Apple 1 1 2.5
2 Banana 1 1 1.5
3 Carrot 2 2 3.0
4 Broccoli 2 2 2.0
5 Chicken 3 3 5.0
6 Beef 3 3 7.0

Пример запроса на выборку продуктов, цена которых меньше 3 и сортировка по убыванию цены:

SELECT *
FROM Products
WHERE Price < 3
ORDER BY Price DESC;

Результат:

ProductID ProductName SupplierID CategoryID Price
2 Banana 1 1 1.5
4 Broccoli 2 2 2.0
1 Apple 1 1 2.5

Здесь мы используем оператор WHERE для отбора всех записей, у которых цена меньше 3. Затем мы используем ключевое слово ORDER BY для сортировки результатов по убыванию цены (от большей к меньшей). Результат показывает выбранные продукты в порядке убывания цены.

покажи сложный пример отбора на sql

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

Таблица Customers:

CustomerID CustomerName ContactName Country
1 Alfreds Maria Germany
2 Ana Trujillo Ana Mexico
3 Antonio Antonio Mexico
4 Around the Horn Thomas UK
5 Berglunds Christina Sweden

Таблица Orders:

OrderID CustomerID OrderDate
1 2 2022-01-01
2 3 2022-01-02
3 1 2022-01-03
4 2 2022-01-04
5 3 2022-01-05
6 1 2022-01-06

Таблица OrderDetails:

OrderDetailID OrderID ProductID Quantity
1 1 1 5
2 2 2 10
3 3 3 20
4 4 4 15
5 5 5 8
6 6 6 12

Пример запроса на выборку данных о заказах, сделанных в мексиканской компании и общей сумме каждого заказа:

SELECT O.OrderID, C.CustomerName, O.OrderDate,
(SELECT SUM(Quantity) FROM OrderDetails WHERE OrderID = O.OrderID) AS TotalQuantity,
(SELECT SUM(Quantity * Price) FROM OrderDetails OD JOIN Products P ON OD.ProductID = P.ProductID WHERE OD.OrderID = O.OrderID) AS TotalAmount
FROM Orders O JOIN Customers C ON O.CustomerID = C.CustomerID
WHERE C.Country = 'Mexico';

Результат:

OrderID CustomerName OrderDate TotalQuantity TotalAmount
2 Ana Trujillo 2022-01-01 10 15
3 Antonio 2022-01-02 20 60
5 Antonio 2022-01-05 8 40

Здесь мы используем оператор JOIN, чтобы объединить таблицы Customers и Orders, и оператор WHERE для отбора заказов, сделанных мексиканскими компаниями. Затем мы используем вложенные подзапросы для подсчета общего количества продуктов и общей стоимости каждого заказа в таблице OrderDetails. Результат показывает информацию о заказ

покажи другой сложный запрос

Конечно, вот пример запроса на выборку данных из нескольких таблиц с использованием операторов JOIN, условий фильтрации, агрегатных функций и группировки:

Таблица Employees:

EmployeeID LastName FirstName BirthDate HireDate
1 Davolio Nancy 1968-12-08 1992-05-01
2 Fuller Andrew 1965-02-19 1992-08-14
3 Leverling Janet 1963-08-30 1992-04-01
4 Peacock Margaret 1958-09-19 1993-05-03

Таблица Orders:

OrderID EmployeeID OrderDate
1 1 2022-01-01
2 2 2022-01-02
3 3 2022-01-03
4 1 2022-01-04
5 2 2022-01-05
6 3 2022-01-06

Таблица OrderDetails:

OrderDetailID OrderID ProductID Quantity Price
1 1 1 5 2.5
2 2 2 10 1.8
3 3 3 20 1.5
4 4 4 15 2.0
5 5 5 8 3.5
6 6 6 12 1.2

Пример запроса на выборку данных о среднем количестве продуктов в заказе для каждого работника:

SELECT E.EmployeeID, E.LastName, E.FirstName, AVG(TotalQuantity) AS AverageQuantity
FROM Employees E
JOIN Orders O ON E.EmployeeID = O.EmployeeID
JOIN (
SELECT OrderID, SUM(Quantity) AS TotalQuantity
FROM OrderDetails
GROUP BY OrderID
) OD ON O.OrderID = OD.OrderID
GROUP BY E.EmployeeID, E.LastName, E.FirstName;

Результат:

EmployeeID LastName FirstName AverageQuantity
1 Davolio Nancy 10.0
2 Fuller Andrew 9.0
3 Leverling Janet 20.0

Здесь мы используем операторы JOIN для объединения таблиц Employees, Orders и OrderDetails, и агрегатную функцию AVG() для подсчета среднего количества продуктов в каждом заказе. Затем мы группируем результаты по Employee

Закон Конвея

Суть закона заключается в том, что при декомпозиции инженерами крупных задач на более мелкие для передачи части работ коллегам, возникает сложность координации между функциональными подразделениями. Во многих организациях команды разделены в соответствии с теми функциями, которые они выполняют, и существуют в отрыве от других команд. Поэтому структура программного интерфейса системы будет отражать социальные границы организации (организаций), которые её создали, что затрудняет общение. В рамках своих функций команды могут отлично справляться с выполнением своих задач. Однако для того, чтобы создать что-то новое (функцию, продукт и т. д.), командам необходимо кросс-функциональное взаимодействие и совместная работа.

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