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

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

S>>>>Файловые базы всегда были быстрее ибо все происходит в одном процессе.
НС>>>Или не потому.
S>>А за счет чего?

V>1. Запись на файл быстрее за счёт асинхронности.
V>Записывая данные в файл, твоя программа обычно не ожидает завершения фактической записи на диск.
V>Попробуй на каждый чих делать что-то типа Flush() и прочувствуй разницу.
Ну для Dbase там при записи Flush то и используется. Для SQL там различные варианты. Но транзакции кстати ускоряют запись.

V>2. Чтение из файла быстрее за счёт кеширования.
V>При повторном чтении того же файла ты будешь с большой вероятностью читать данные не с диска, а из RAM.
Ну тоже само и для SQL


S>>Интерпретатор выигрывает!

V>Интерпретатор — он для юзверского кода.
V>Но на системном уровне можно было сделать и асинхронщину, и локальное кеширование с синхронизацией.
V>В т.ч. локальное кеширование в локальной БД (я кешировал в локальной БД MS Access).

V>Например, при вводе справочных данных клиент не ожидал ответного суррогатного auto-number ключа, т.к. клиент еще в начале работы резервирует себе уникальный список ключей, т.е. всегда при вставке знает суррогатный ключ справочной записи, поэтому ему не требуется синхронно ожидать ответ для продолжения работы.
Так файловые базы это чисто юзверский код. А что касается ключей то и в 1С есть стратегии
Но GUID у них тоже своеобразный. Он формируется из нормального гуида но в нем есть дата и автоинкремент.
https://infostart.ru/1c/articles/635159/
Здесь уже обсуждали UUIDv6

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

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

S>>>>Файловые базы всегда были быстрее ибо все происходит в одном процессе.
НС>>>Или не потому.
S>>А за счет чего?

V>1. Запись на файл быстрее за счёт асинхронности.
V>Записывая данные в файл, твоя программа обычно не ожидает завершения фактической записи на диск.
V>Попробуй на каждый чих делать что-то типа Flush() и прочувствуй разницу.
Ну для Dbase там при записи Flush то и используется. Для SQL там различные варианты. Но транзакции кстати ускоряют запись.

V>2. Чтение из файла быстрее за счёт кеширования.
V>При повторном чтении того же файла ты будешь с большой вероятностью читать данные не с диска, а из RAM.
Ну тоже само и для SQL


S>>Интерпретатор выигрывает!

V>Интерпретатор — он для юзверского кода.
V>Но на системном уровне можно было сделать и асинхронщину, и локальное кеширование с синхронизацией.
V>В т.ч. локальное кеширование в локальной БД (я кешировал в локальной БД MS Access).

V>Например, при вводе справочных данных клиент не ожидал ответного суррогатного auto-number ключа, т.к. клиент еще в начале работы резервирует себе уникальный список ключей, т.е. всегда при вставке знает суррогатный ключ справочной записи, поэтому ему не требуется синхронно ожидать ответ для продолжения работы.
Так файловые базы это чисто юзверский код. А что касается ключей то и в 1С есть стратегии
Но GUID у них тоже своеобразный. Он формируется из нормального гуида но в нем есть дата и автоинкремент.
https://infostart.ru/1c/articles/635159/
Здесь уже обсуждали UUIDv6
есть GUID'ы, которые используют текущее время в качестве префикса. http://gh.peabody.io/uuidv6/