Только учтите что скуль на "сервере" (обычный комп) и на Сервере это две большие разницы.
Дисковая подсистема хорошая, решает сильно.
Только учтите что скуль на "сервере" (обычный комп) и на Сервере это две большие разницы.
Скажу про SQLAnywhere, Firebird - недоскуль в этом смысле. Так вот, SQLAnywhere пытается запихнуть всю базу в память. Даже транзакции на добавление, удаление, изменение не пишутся сразу, ведётся только лог на случай потери питания. Поэтому запрос делается фактически только в памяти. Поэтому, мне кажется, скорость однозначно у SQL будет больше. Даже, если всё не помещается в памяти , то сервак "кэширует" запросы, второй такой-же запрос может идти на порядок быстрее. Сейчас у грандов появился режим In-Memory, при включении даже лог не пишется (страшно аж жуть).Admin писал(а):Только учтите что скуль на "сервере" (обычный комп) и на Сервере это две большие разницы.
Дисковая подсистема хорошая, решает сильно.
Я не уговариваю. Вопрос о целесообразности перехода. Я когда-то тоже думал на эту тему и экспериментировал с postgresql. Довольно плотно, даже нашел схему, при которой можно не использовать серверные курсоры и достаточно приемлемо работать с постраничным броузом на табличках с несколькими миллионами записей (там через callback подсовывался limit в запросы, а в настройках odbc использование серверных курсоров не включалось).kreator писал(а): Не уговоришь на терминалку. Я как-то пропустил эту тему, возможно, тогда и не было терминального сервера. А теперь назад не пойду. Всё равно, мне кажется, скуль быстрее будет (и надёжнее). Скорость надо сравнивать, например, запросом по связанным пяти таблицам, имеющим по паре миллионов записей.
Имеется ввиду дисковый кэш винды. Эффект можно легко увидеть на глаз. После перезагрузки сервера запускаем формирование какого-нибудь сложного отчета. Затем входим под другим пользователем и запускаем тот же отчет. Разница может быть на порядок. Это называют "прогрев кэша".
Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
2002-2003 года, но сервак был крутой - контора солидная. А 10-15 мин все равно не сопоставимо с долями секунд...finsoftrz писал(а):Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
Да, это так. При разработке на tps надо заранее предусматривать индексы и использовать их в коде. С одной стороны, это определенная работа, с другой стороны все без сюрпризов. Приложения с tps быстрее обрабатывают отдельные записи, sql-сервера заточены под массовые выборки. И это принципиально влияет на архитектуру приложения. И на мышление при разработке. Но я бы сказал, что в обоих случаях можно получить хороший результат, только несколько разными путями. Одно время sql-сервера были мэйнстримом, их активно продвигали в противовес файл-серверным системам, для оптимизации распределенного управления ресурсами. Сейчас это уже не совсем так, мощности выросли и мэйнстримом стал NoSQL. Пока эта тенденция в основном касается больших баз данных. Кстати, бывшая команда topspeed свалила именно в эту область.
Ну, структура данных дл больших таблиц меняется далеко не каждый месяц... В данном случае, операции разные.PavelNK писал(а):2002-2003 года, но сервак был крутой - контора солидная. А 10-15 мин все равно не сопоставимо с долями секунд...finsoftrz писал(а):Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
Kreator, моё почтение. Здесь речь шла о разработчиках на стороне клиента? Для этого желателен SQL-синтакс? Поясни, пож.kreator писал(а): ODBC, конечно, выход, но не туда. Если сравнивать с SQLite, которому он не нужен. Есть достаточно надёжная, быстро работающая файловая БД (это я про TPS). Осталось только прикрутить SQL-синтакс и давать разработчикам библиотеку для работы. Пусть в dll, пусть за небольшие деньги, пусть с ограниченным функционалом (с неограниченным при работе через Clarion). И дело бы пошло.
Я уже где-то писал (может здесь) - у нас есть такой функционал. Пользователь может ввести SQL-запрос (как есть, например) и получить результат в виде банальной не форматированной выгрузки в Excel. Но функционал не востребован совсем. Во-первых, нужно очень хорошо знать структуру данных (таблицы, связи ...). Во-вторых, нужно очень хорошо знать сам SQL, плюс его диалекты. Создать запрос по пяти нетривиально связанным таблицам - уже непростое дело даже для нас. Сидим, например, в IBExpert'е, крутим, вертим, типа оптимизируем. Хотя "потенциальные" заказчики, когда приходят посмотреть продукт, обычно спрашивают - "Можно что-нибудь самим наваять?". Причём, естественно, не хотят сильно вникать в тему, хотят очень простой механизм. У нас нет идеи - как сделать простой механизм как для запросов, так и для генерации, допустим, отчётов. Есть на рынке коммерческие продукты, которые это позволяют сделать, подключившись напрямую к БД (по-моему, IBM Cognos достаточно продвинутая вещь в этом плане).Shur писал(а):Kreator, моё почтение. Здесь речь шла о разработчиках на стороне клиента? Для этого желателен SQL-синтакс? Поясни, пож.