VD>По сравнению с доступом к БД — это фигня. Датасет вообще по скорости меня удовлетворяет. Кстати, нафиг там боксинг я так ни не понял. Могли бы сделать типизированный доступ.
Реальные запрсы выглядят так же как и известный тебе ДБФ c различной реализацией заголовочной частью.
Далее массив данных. Выборка SQL с группировками с иерархической структурой тебя тоже удовлетворяет????
Вот поэтому 1С дбф + TSE обгоняет SQL на порядок. А при прямом доступе разница между черепашьей скоростью 1С состовляет от 30 и выше. А при хранение данных не в строковом формате (BCD) а в нормальном все выполняется мнгновенно при кэшировании файлов, или применении Raid массивов.
Здравствуйте, Serginio1, Вы писали:
S> Реальные запрсы выглядят так же как и известный тебе ДБФ c различной реализацией заголовочной частью.
Не понял, но ладно...
S> Далее массив данных. Выборка SQL с группировками с иерархической структурой тебя тоже удовлетворяет????
Они мне не нужны. Группировку я и сам сделаю. А иерархию тащить одним запростом — это вообще безсмысленно. Или выну все ветки и построю дерево в коде, или буду вынимать по одной ветке.
S> Вот поэтому 1С дбф + TSE обгоняет SQL на порядок.
Не. Она просто кривая (я о 7-ке). И обогнать она можеть только покайника при любой реализации.
S> А при прямом доступе разница между черепашьей скоростью 1С состовляет от 30 и выше. А при хранение данных не в строковом формате (BCD) а в нормальном все выполняется мнгновенно при кэшировании файлов, или применении Raid массивов.
Я как то пробовал писать для MSSQL и Оракла. И мне показалось, что это было несколько быстрее чем 1С.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Реальные запрсы выглядят так же как и известный тебе ДБФ c различной реализацией заголовочной частью.
VD>Не понял, но ладно...
Структура данных получамых клиентом.
S>> Далее массив данных. Выборка SQL с группировками с иерархической структурой тебя тоже удовлетворяет????
VD>Они мне не нужны. Группировку я и сам сделаю. А иерархию тащить одним запростом — это вообще безсмысленно. Или выну все ветки и построю дерево в коде, или буду вынимать по одной ветке.
На клиенте или на хранимых процедурах??? S>> Вот поэтому 1С дбф + TSE обгоняет SQL на порядок.
VD>Не. Она просто кривая (я о 7-ке). И обогнать она можеть только покайника при любой реализации.
Если посмотреть на модуль проведения в 1С никакой T-SQL не справится. Придется таскать данные с сервера на клиент. Даже компиляторы на клиенте не помогут (TSE и трехзвенка решают проблемы, но где же конкуренты)
S>> А при прямом доступе разница между черепашьей скоростью 1С состовляет от 30 и выше. А при хранение данных не в строковом формате (BCD) а в нормальном все выполняется мнгновенно при кэшировании файлов, или применении Raid массивов.
VD>Я как то пробовал писать для MSSQL и Оракла. И мне показалось, что это было несколько быстрее чем 1С.
Порядок???? При нормальном хранении данных и прямом доступе миллионные выборки с группировками!!! до 300 000 менее 1 сек (разумеется на откэшированных файлах и размером 50 mb)
Извини нагорело.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
VD>>Они мне не нужны. Группировку я и сам сделаю. А иерархию тащить одним запростом — это вообще безсмысленно. Или выну все ветки и построю дерево в коде, или буду вынимать по одной ветке. S> На клиенте или на хранимых процедурах???
Нахрена они мне в хранимых процедурах? Не, ну, понадобится... засуним.
S>>> Вот поэтому 1С дбф + TSE обгоняет SQL на порядок.
S> Если посмотреть на модуль проведения в 1С никакой T-SQL не справится. Придется таскать данные с сервера на клиент. Даже компиляторы на клиенте не помогут (TSE и трехзвенка решают проблемы, но где же конкуренты)
Это все проблемы кривой архитектуры. В нормальной трехзвенке на клиента нужно тачить только конечные данные.
S> Порядок???? При нормальном хранении данных и прямом доступе миллионные выборки с группировками!!! до 300 000 менее 1 сек (разумеется на откэшированных файлах и размером 50 mb)
И в чем проблема? Современные серверы на современных машинах с такой скорость и работают. 50 мег вообще фигня. А если применить разные индексированные представления...
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
VD>>>Они мне не нужны. Группировку я и сам сделаю. А иерархию тащить одним запростом — это вообще безсмысленно. Или выну все ветки и построю дерево в коде, или буду вынимать по одной ветке. S>> На клиенте или на хранимых процедурах???
VD>Нахрена они мне в хранимых процедурах? Не, ну, понадобится... засуним.
S>>>> Вот поэтому 1С дбф + TSE обгоняет SQL на порядок.
S>> Если посмотреть на модуль проведения в 1С никакой T-SQL не справится. Придется таскать данные с сервера на клиент. Даже компиляторы на клиенте не помогут (TSE и трехзвенка решают проблемы, но где же конкуренты)
VD>Это все проблемы кривой архитектуры. В нормальной трехзвенке на клиента нужно тачить только конечные данные.
S>> Порядок???? При нормальном хранении данных и прямом доступе миллионные выборки с группировками!!! до 300 000 менее 1 сек (разумеется на откэшированных файлах и размером 50 mb)
VD>И в чем проблема? Современные серверы на современных машинах с такой скорость и работают. 50 мег вообще фигня. А если применить разные индексированные представления...
Только одним запросом ты данные не вытянешь.
Простой пример с вышеперечисленными результатами. Есть остатки есть движения товаров. Мне нужно посчитать количествой дней нахождение товара + количество проданного товара и периоды продаж (разница в днях между продажами). Затем усечь дни нахождения в продаже на недостоверно долгое время не продаж товаров. Все это для более достоверного прогноза времени и количества закупки и определения мертвых душ или не выставленного в продажу товара, что при большом ассортименте встречается очень часто.
Объем большой роли не играет, а количество записей на откэшируемых файлах.
Очень интересно посмотреть на твой подход для решения данной задачи на SQL.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Только одним запросом ты данные не вытянешь.
С чего бы это? Вроде с SQL знаком давно. Раньше удавалось.
S> Простой пример с вышеперечисленными результатами. Есть остатки есть движения товаров. Мне нужно посчитать количествой дней нахождение товара + количество проданного товара и периоды продаж (разница в днях между продажами). Затем усечь дни нахождения в продаже на недостоверно долгое время не продаж товаров. Все это для более достоверного прогноза времени и количества закупки и определения мертвых душ или не выставленного в продажу товара, что при большом ассортименте встречается очень часто.
читавл?
S> Объем большой роли не играет, а количество записей на откэшируемых файлах. S> Очень интересно посмотреть на твой подход для решения данной задачи на SQL.
А он у всех один. Подзапросы и вьюшки. Можно индексированные.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Только одним запросом ты данные не вытянешь.
VD>С чего бы это? Вроде с SQL знаком давно. Раньше удавалось.
S>> Простой пример с вышеперечисленными результатами. Есть остатки есть движения товаров. Мне нужно посчитать количествой дней нахождение товара + количество проданного товара и периоды продаж (разница в днях между продажами). Затем усечь дни нахождения в продаже на недостоверно долгое время не продаж товаров. Все это для более достоверного прогноза времени и количества закупки и определения мертвых душ или не выставленного в продажу товара, что при большом ассортименте встречается очень часто.
VD>Вот это
читавл?
То есть созданием дополнительной таблицы заточенной под данный отчет (OLAP)?????
Но тогда при объемах номенклатуры за 10 тыс база вырастет непомерно быстро, причем будет повторять но только в большем объеме уже имеющую информацию. Это от бедности. Еще очень интересная вещь проведение задним числом, очень часто применяемая в нашей стране в отличе от запада где такие вещи вообще не предусматриваются, только корректирующей записью.
S>> Объем большой роли не играет, а количество записей на откэшируемых файлах. S>> Очень интересно посмотреть на твой подход для решения данной задачи на SQL.
VD>А он у всех один. Подзапросы и вьюшки. Можно индексированные.
Вот и интересно посмотреть. Потому, что многие вещи плохо вписываются в SQL. А на хранимых процедурах, тоже много не напишешь, да и по отзывам трех звенка быстрее работает чем навороченные ХП с курсорами.
С удовольствием предоставлю свой код. Кроме всего прочего при группировании мне не нужно использовать индекс на вторую группировку по дате, используя индекс выборки все сводится к однонаправленным спискам.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> То есть созданием дополнительной таблицы заточенной под данный отчет (OLAP)?????
Ну, и это тоже. Но вообще-то там паказано за одно и как делать отностельно сложные запросы в одном запросе.
S> Но тогда при объемах номенклатуры за 10 тыс база вырастет непомерно быстро, причем будет повторять но только в большем объеме уже имеющую информацию. Это от бедности.
Хранятся исключительно агрегаты, а они по определению значительно меньше.
S>Еще очень интересная вещь проведение задним числом, очень часто применяемая в нашей стране в отличе от запада где такие вещи вообще не предусматриваются, только корректирующей записью.
А какие проблемы? Если речь об автоматически перещитываемых оборотах, то они просто пересчитаются.
S> Вот и интересно посмотреть. Потому, что многие вещи плохо вписываются в SQL.
Нормально вписывается. Просто запросы становятся сложными и их уже имеет смысл генерировать, а не писать вручную.
S> А на хранимых процедурах, тоже много не напишешь,
И это скажем так не так. Много чего на них можно. Вот скоро выйдет Юкон (mssql 9) и процедуры можно будет писать на Шарпе или МС++. В Оракле уже давно язык очень приличный, да и Ява есть. В DB2 тоже Ява. Так что все пучком.
S> да и по отзывам трех звенка быстрее работает чем навороченные ХП с курсорами.
Чушь это. Не слушай таких людей. Трехзвенка наоборот замедляет быстродействие. Другое дело масштабирование (паралелельнье на нескольких серверах).
Да зачем собственно трехзвенка должна соперничать с sql-серверами? Sql — это выборка и обработка данных в слое данных. Мидлтаер — это логика и т.п. Они прекрасно сочетаются вместе.
S> С удовольствием предоставлю свой код. Кроме всего прочего при группировании мне не нужно использовать индекс на вторую группировку по дате, используя индекс выборки все сводится к однонаправленным спискам.
И скольок при этом кода?
В общем, давно доказано, что серверы БД построенные по технологии клиент-сервер превосходят любой ISAM в более менее сложных задачах. Они и уровень абстаркции повышают и расчеты позволяют более оптимально делать. Ну, а главное, обладают несравнимо более высокой надежностью.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> То есть созданием дополнительной таблицы заточенной под данный отчет (OLAP)?????
VD>Ну, и это тоже. Но вообще-то там паказано за одно и как делать отностельно сложные запросы в одном запросе.
Я такие навороты видел, что как сервер при нормальных объемах сдохнет, на каждом запрсе вызываеися подзапрос с уже вычисленными данными. S>> Но тогда при объемах номенклатуры за 10 тыс база вырастет непомерно быстро, причем будет повторять но только в большем объеме уже имеющую информацию. Это от бедности.
VD>Хранятся исключительно агрегаты, а они по определению значительно меньше.
В контексте моей задачи с усечением неопраданно долгих интервалов не продаж, все равно придеся расчитывать статистику или ее накапливать. Но зачем это нужно, когда одним проходом я итак все вычисляю за секунды. У тебя запрос к серверу может столько состовлять а ито и дольше
S>>Еще очень интересная вещь проведение задним числом, очень часто применяемая в нашей стране в отличе от запада где такие вещи вообще не предусматриваются, только корректирующей записью.
VD>А какие проблемы? Если речь об автоматически перещитываемых оборотах, то они просто пересчитаются.
Еще раз посмотри задачу. Слишком много пересчитывать придется. S>> Вот и интересно посмотреть. Потому, что многие вещи плохо вписываются в SQL.
VD>Нормально вписывается. Просто запросы становятся сложными и их уже имеет смысл генерировать, а не писать вручную.
S>> А на хранимых процедурах, тоже много не напишешь,
VD>И это скажем так не так. Много чего на них можно. Вот скоро выйдет Юкон (mssql 9) и процедуры можно будет писать на Шарпе или МС++. В Оракле уже давно язык очень приличный, да и Ява есть. В DB2 тоже Ява. Так что все пучком.
Често говоря я его (Юкон) тоже очень жду. Тогда и для меня лично все пучком будет. Только останется купить. Но при этом и узкоспециализированные вещи можно писать и без сторонних БД.
S>> да и по отзывам трех звенка быстрее работает чем навороченные ХП с курсорами.
VD>Чушь это. Не слушай таких людей. Трехзвенка наоборот замедляет быстродействие. Другое дело масштабирование (паралелельнье на нескольких серверах).
VD>Да зачем собственно трехзвенка должна соперничать с sql-серверами? Sql — это выборка и обработка данных в слое данных. Мидлтаер — это логика и т.п. Они прекрасно сочетаются вместе.
S>> С удовольствием предоставлю свой код. Кроме всего прочего при группировании мне не нужно использовать индекс на вторую группировку по дате, используя индекс выборки все сводится к однонаправленным спискам.
VD>И скольок при этом кода?
Кода там в модуле на 700 строк, но сам выборки алгоритм 80 строк и обработке коррекции еще 100 строк ну 300. Но построен на объектах без филдов а прямой доступ к считанной записи. VD>В общем, давно доказано, что серверы БД построенные по технологии клиент-сервер превосходят любой ISAM в более менее сложных задачах. Они и уровень абстаркции повышают и расчеты позволяют более оптимально делать. Ну, а главное, обладают несравнимо более высокой надежностью.
А кто мешает использовать через теже сокеты или DCom делать свой сервер на локальных базах. Да и применение транзакций только для отката и применении синхронизации MultiReadWriteExclusive при использовании раннего связывания и окомпилированного кода можно обходить все SQL. А можно и на своих иерархически построенных данных. Да скорость разработки резко уменьшится, но если посчитать человеко годы которые были сэкономлены даже в моей работе при оптимизации 1С все окупается сторицей. Для каждой задачи свой инструмент. И в одних задачах лучше SQL не найти. Просто он позиционируется как панацея от всех бед. Но это не так.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Я такие навороты видел, что как сервер при нормальных объемах сдохнет, на каждом запрсе вызываеися подзапрос с уже вычисленными данными.
На практике все пучком. Запросы к тому же оптимизируются.
S> В контексте моей задачи с усечением неопраданно долгих интервалов не продаж, все равно придеся расчитывать статистику или ее накапливать. Но зачем это нужно, когда одним проходом я итак все вычисляю за секунды. У тебя запрос к серверу может столько состовлять а ито и дольше
Если за секунды, то и на SQL-е он будет секунды выполняться. А то и быстрее. Все же севрер работает на низком уровне.
S> Еще раз посмотри задачу. Слишком много пересчитывать придется.
Ну, сколько есть. От рукопашного лазенья по ISAM-базе особо быстрее не будет.
S> Често говоря я его (Юкон) тоже очень жду. Тогда и для меня лично все пучком будет. Только останется купить. Но при этом и узкоспециализированные вещи можно писать и без сторонних БД.
В Оракле и ДБ2 это уже давно есть. Да и на транзакте все же многое написать можно. Просто не нужно логику в транзакте обрабатывать.
S> Кода там в модуле на 700 строк, но сам выборки алгоритм 80 строк и обработке коррекции еще 100 строк ну 300. Но построен на объектах без филдов а прямой доступ к считанной записи.
А что за БД?
S> А кто мешает использовать через теже сокеты или DCom делать свой сервер на локальных базах.
Их убогость и ненадежность.
S> Да и применение транзакций только для отката и применении синхронизации MultiReadWriteExclusive при использовании раннего связывания и окомпилированного кода можно обходить все SQL.
Не понял.
S> А можно и на своих иерархически построенных данных. Да скорость разработки резко уменьшится, но если посчитать человеко годы которые были сэкономлены даже в моей работе при оптимизации 1С все окупается сторицей. Для каждой задачи свой инструмент. И в одних задачах лучше SQL не найти. Просто он позиционируется как панацея от всех бед. Но это не так.
Ну, не знаю. Для меня 1С — это просто приговор всему разумному, доброму и вечному.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Я такие навороты видел, что как сервер при нормальных объемах сдохнет, на каждом запрсе вызываеися подзапрос с уже вычисленными данными.
VD>На практике все пучком. Запросы к тому же оптимизируются.
S>> В контексте моей задачи с усечением неопраданно долгих интервалов не продаж, все равно придеся расчитывать статистику или ее накапливать. Но зачем это нужно, когда одним проходом я итак все вычисляю за секунды. У тебя запрос к серверу может столько состовлять а ито и дольше
VD>Если за секунды, то и на SQL-е он будет секунды выполняться. А то и быстрее. Все же севрер работает на низком уровне.
Считывание данных из кэша будет одинакова. Данные считанные в запись уже пригодны для использования на раннем знание о структуре и компилятор подставляет уже известное на этапе компиляции смещение без применения филдов. S>> Еще раз посмотри задачу. Слишком много пересчитывать придется.
VD>Ну, сколько есть. От рукопашного лазенья по ISAM-базе особо быстрее не будет.
S>> Често говоря я его (Юкон) тоже очень жду. Тогда и для меня лично все пучком будет. Только останется купить. Но при этом и узкоспециализированные вещи можно писать и без сторонних БД.
VD>В Оракле и ДБ2 это уже давно есть. Да и на транзакте все же многое написать можно. Просто не нужно логику в транзакте обрабатывать.
Эх мне бы их покатать со знающим человеком, но нет возможности. S>> Кода там в модуле на 700 строк, но сам выборки алгоритм 80 строк и обработке коррекции еще 100 строк ну 300. Но построен на объектах без филдов а прямой доступ к считанной записи.
VD>А что за БД?
дбф 1С. S>> А кто мешает использовать через теже сокеты или DCom делать свой сервер на локальных базах.
VD>Их убогость и ненадежность.
А что используется при подключении к MS SQL ???? S>> Да и применение транзакций только для отката и применении синхронизации MultiReadWriteExclusive при использовании раннего связывания и окомпилированного кода можно обходить все SQL.
VD>Не понял.
Создать движок аля ДБФ не большая проблема. Лучше сразу же иерархическую БД. Но даже на дбф постоение архитектуры Клиент-Сервер не сложная задача но с передачей данных от клиента в бинарном сериализованном виде. И выполнении всех запросов через удаленные специально заточенные процедуры.
S>> А можно и на своих иерархически построенных данных. Да скорость разработки резко уменьшится, но если посчитать человеко годы которые были сэкономлены даже в моей работе при оптимизации 1С все окупается сторицей. Для каждой задачи свой инструмент. И в одних задачах лучше SQL не найти. Просто он позиционируется как панацея от всех бед. Но это не так.
VD>Ну, не знаю. Для меня 1С — это просто приговор всему разумному, доброму и вечному.
Это ты не умеешь ее приготавливать. Оказывается на данных 1С очень легко строится объектная модель и скорость при использовании компилятора ого го. Но это на безрыбье и на строковых (BCD) данных. А если создать свою БД то .... Не суждено моим мечтам сбыться.
Но при том, что такую же 1С можно содать на Net не видно конкурентов. А свободных решений на этой платформе огромное количество. Но нет такой базы решений на других языках. Все держаться за свои наработки. И на конференциях одни и теже вопросы.
А связался я с ней когда была нужна уже готовая программа с возможностью ее переделки под свои условия. Если бы я сел за написане своей БД думаю не скоро ее бы сварганил. И стал я 1С программистом.
Страна имеет такие программы которые заслуживает.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Считывание данных из кэша будет одинакова. Данные считанные в запись уже пригодны для использования на раннем знание о структуре и компилятор подставляет уже известное на этапе компиляции смещение без применения филдов.
Нет. Кэш mssql-я значительно эффектинвнее кэша файловой системы ОС. В общем, можно провести эксперементы.
S> Эх мне бы их покатать со знающим человеком, но нет возможности.
А в чем проблема то?
S> дбф 1С.
Думаю супротив ДБФ сиквелсервер будет точно быстре.
VD>>Их убогость и ненадежность. S> А что используется при подключении к MS SQL ????
Не понял? MS SQL сам по себе обеспечивает SQL92-совместимый SQL (мощьный и удобный) и великолепную надежность.
S> Создать движок аля ДБФ не большая проблема. Лучше сразу же иерархическую БД. Но даже на дбф постоение архитектуры Клиент-Сервер не сложная задача но с передачей данных от клиента в бинарном сериализованном виде. И выполнении всех запросов через удаленные специально заточенные процедуры.
А зачем что-то делать если это уже сделано. Вряд ли ты сможешь сделать более эффективный сервер чем топовые (МС, ДБ2, Оракл). У них все оптимально, от хранения данных, до комуникационных интерфейсов.
S> Это ты не умеешь ее приготавливать.
Слишком уж многие этого не умеют.
S> Оказывается на данных 1С очень легко строится объектная модель и скорость при использовании компилятора ого го. Но это на безрыбье и на строковых (BCD) данных. А если создать свою БД то .... Не суждено моим мечтам сбыться.
Это велосипед. В БД 1С нет главного. В них нет логики. Это всего лишь таблицы продаваемые под соусом документов и справочников. А при доступе через ДБФ они и во все превращаются в плоские таблицы.
S> Но при том, что такую же 1С можно содать на Net не видно конкурентов. А свободных решений на этой платформе огромное количество. Но нет такой базы решений на других языках. Все держаться за свои наработки. И на конференциях одни и теже вопросы.
За аналог 1С но с "мозгами" я бы тоже взялся. Но реализовывать нечто на ядре 1С... мне это не нравится. У меня есть свои мысли о учетнгм ядре. Думаю их реализация оказалась бы намного предпочтительнее 1С-а.
S> А связался я с ней когда была нужна уже готовая программа с возможностью ее переделки под свои условия. Если бы я сел за написане своей БД думаю не скоро ее бы сварганил. И стал я 1С программистом.
Может подошла пора пора осмыслить опыт и сесть за реализацию собственой вариации?
S> Страна имеет такие программы которые заслуживает.
Ну, уж нет. В стране не мало и нормальных програм. Просто Нуралиев очень хорошо нучился торговать софтом в этой стране. Думаю, что он бы смог впарить и любую другую систему.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Считывание данных из кэша будет одинакова. Данные считанные в запись уже пригодны для использования на раннем знание о структуре и компилятор подставляет уже известное на этапе компиляции смещение без применения филдов.
VD>Нет. Кэш mssql-я значительно эффектинвнее кэша файловой системы ОС. В общем, можно провести эксперементы.
S>> Эх мне бы их покатать со знающим человеком, но нет возможности.
VD>А в чем проблема то?
Нет у меня знакомых. Варюсь в собственном котле.
S>> дбф 1С.
VD>Думаю супротив ДБФ сиквелсервер будет точно быстре.
Вот и интересно проверить. Я привожу только свои данные данные. А хранение данных типа Numeric .... Интересно сравнить. Даже поиск методом Боуера-Мура с приведением к верхнему регистру пашет в сотых долях секунды на 12 тыс записей считывании записей блоками. Аналогичный запрос на SQL по не моим данным дольше.
VD>>>Их убогость и ненадежность. S>> А что используется при подключении к MS SQL ????
VD>Не понял? MS SQL сам по себе обеспечивает SQL92-совместимый SQL (мощьный и удобный) и великолепную надежность.
Ну MS SQL тоже падают не реже чем дбф. Восстановление тоже, что и дбф при повреждении журнала транзакций. S>> Создать движок аля ДБФ не большая проблема. Лучше сразу же иерархическую БД. Но даже на дбф постоение архитектуры Клиент-Сервер не сложная задача но с передачей данных от клиента в бинарном сериализованном виде. И выполнении всех запросов через удаленные специально заточенные процедуры.
VD>А зачем что-то делать если это уже сделано. Вряд ли ты сможешь сделать более эффективный сервер чем топовые (МС, ДБ2, Оракл). У них все оптимально, от хранения данных, до комуникационных интерфейсов.
А почему бы и нет. Разный подход. Это отнюдь не велосипед ведь еще и Каша есть.
А сколько они стоят?????? Когда речь идет о суммах около 1МБ ( мега бакса) я думаю заоптимизироваться можно. (акзапта итд) S>> Это ты не умеешь ее приготавливать.
VD>Слишком уж многие этого не умеют.
S>> Оказывается на данных 1С очень легко строится объектная модель и скорость при использовании компилятора ого го. Но это на безрыбье и на строковых (BCD) данных. А если создать свою БД то .... Не суждено моим мечтам сбыться.
VD>Это велосипед. В БД 1С нет главного. В них нет логики. Это всего лишь таблицы продаваемые под соусом документов и справочников. А при доступе через ДБФ они и во все превращаются в плоские таблицы.
Многомерный массив по сути являет из себя одномерный. Другой вопрос, что из РБД конфетку не зделаешь, хотя... S>> Но при том, что такую же 1С можно содать на Net не видно конкурентов. А свободных решений на этой платформе огромное количество. Но нет такой базы решений на других языках. Все держаться за свои наработки. И на конференциях одни и теже вопросы.
VD>За аналог 1С но с "мозгами" я бы тоже взялся. Но реализовывать нечто на ядре 1С... мне это не нравится. У меня есть свои мысли о учетнгм ядре. Думаю их реализация оказалась бы намного предпочтительнее 1С-а.
И я об этом думаю. С удовольствием занялся аналогичным проектом желательно на своей базе но на безрыбье и ....
S>> А связался я с ней когда была нужна уже готовая программа с возможностью ее переделки под свои условия. Если бы я сел за написане своей БД думаю не скоро ее бы сварганил. И стал я 1С программистом.
VD>Может подошла пора пора осмыслить опыт и сесть за реализацию собственой вариации?
Пора давно пришла. Но еще не пришел Юкон, а свою БД создавать одному сложно но можно, но писать в стол не хочется. S>> Страна имеет такие программы которые заслуживает.
VD>Ну, уж нет. В стране не мало и нормальных програм. Просто Нуралиев очень хорошо нучился торговать софтом в этой стране. Думаю, что он бы смог впарить и любую другую систему.
В том числе. Но платформа V7 объективно была нужна. Но время идет а воз и ныне там (V8 улучшенная версия не более).
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Нет у меня знакомых. Варюсь в собственном котле.
Да там и так все не очень сложно. Кстати, если речь именно об ОО-надстройке, то может лучше просто взять ОО-БД? Например, Каше...
VD>>Думаю супротив ДБФ сиквелсервер будет точно быстре. S> Вот и интересно проверить. Я привожу только свои данные данные. А хранение данных типа Numeric .... Интересно сравнить. Даже поиск методом Боуера-Мура с приведением к верхнему регистру пашет в сотых долях секунды на 12 тыс записей считывании записей блоками. Аналогичный запрос на SQL по не моим данным дольше.
12 тысячь это вообще не цифра. Это мгновенно будет на любых данных. Тормоза могут начаться на значениях от миллиона. Провести же тест не так сложно. Создай тестовую БД, напиши тест для ДБФ, а я портирую его на сиквил. Потом можно будет и с Эксесом сравнить. Глядишь еще один шустрик получится.
VD>>Не понял? MS SQL сам по себе обеспечивает SQL92-совместимый SQL (мощьный и удобный) и великолепную надежность. S> Ну MS SQL тоже падают не реже чем дбф. Восстановление тоже, что и дбф при повреждении журнала транзакций.
Ни разу не видел. Слышал один раз как раз в сочетании с 1С. И это был MSSQL 6.x.
В отличии от ДБФ в сиквеле используются журналирование. ДБФ-у до этого очень далеко.
S> А почему бы и нет. Разный подход. Это отнюдь не велосипед ведь еще и Каша есть.
Каша это Кашэ? Так это полноценный сервер в который вложено очень не мало усилий и идей.
S> А сколько они стоят?????? Когда речь идет о суммах около 1МБ ( мега бакса) я думаю заоптимизироваться можно. (акзапта итд)
Даже на Оракле таких цен никогда не видел. Тот же МС имеется в бесплатном однопользовательском варианте.
S> И я об этом думаю. С удовольствием занялся аналогичным проектом желательно на своей базе но на безрыбье и ....
Можно из заняться. Сделать открытый проект... Вот только своя БД — это перебор. Незачем это. Так никогда незакончишь.
S> Я понимаю, что мои наработки детский лепет, но хотел бы узнать твое мнение S>http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019
Какое мнение? Это надстройка над тем, что мне по любому не нравится. Как бы она не была хороша...
S> Пора давно пришла. Но еще не пришел Юкон, а свою БД создавать одному сложно но можно, но писать в стол не хочется.
Да не нужен тут Юкон. С ним было бы конечно проще. Но и без него все будет раборть. Тут нужно реализовывать идеи... Того же MSSQL 2000 за глаза хватит. Просто нужно еще некую горку кода написать.
S> В том числе. Но платформа V7 объективно была нужна.
Не платформа V7, а некий конструктор с пребилднутыми конфигурациями.
S>Но время идет а воз и ныне там (V8 улучшенная версия не более).
Я про весмерку только слышал, но сам не видел. Слышал что они там клиент-сервер (трехзвенку) залудили. Но что там появилось с точки зрения разума в системе не знаю. Вот бы кто поведал...
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>12 тысячь это вообще не цифра. Это мгновенно будет на любых данных. Тормоза могут начаться на значениях от миллиона. Провести же тест не так сложно. Создай тестовую БД, напиши тест для ДБФ, а я портирую его на сиквил. Потом можно будет и с Эксесом сравнить. Глядишь еще один шустрик получится.
Время на обработку для компилятора миллионных данных пустяк, все упирается в кэщировании файлов. Если Raid массивы позволяют считывать от 100 мб в сек. этим и лимитируется скорость. Но при повторном чтении скорость считывания достигает 150 мб за 0.375 сек.
Возьми мой пример иерархической БД и сравни если хочешь. Самому очень интересно. Или пришли свои таблицы, а с ними поработаю с прямым доступом без индексов, или построением своих индексов или хэш-таблиц с учетом этого времени.
Но уверяю, что прямой доступ с ранним связыванием будет всегда быстрее.
S>> Ну MS SQL тоже падают не реже чем дбф. Восстановление тоже, что и дбф при повреждении журнала транзакций.
VD>Ни разу не видел. Слышал один раз как раз в сочетании с 1С. И это был MSSQL 6.x.
А я не один раз так как иногда захожу на 1С форумы. Диски летят. VD>В отличии от ДБФ в сиквеле используются журналирование. ДБФ-у до этого очень далеко.
Ну акто запрещает сделать это самому???? При чем я не сторонник РБД а уж DBF тем более. S>> А почему бы и нет. Разный подход. Это отнюдь не велосипед ведь еще и Каша есть.
VD>Каша это Кашэ? Так это полноценный сервер в который вложено очень не мало усилий и идей.
Да. Но опять же универсальный. Нужно делать специально заточенную базу ИМХО. S>> А сколько они стоят?????? Когда речь идет о суммах около 1МБ ( мега бакса) я думаю заоптимизироваться можно. (акзапта итд)
VD>Какое мнение? Это надстройка над тем, что мне по любому не нравится. Как бы она не была хороша...
ОО Надстройку можно делать над чем угодно, главное грамотно создать и прописать метаданные (схему бд и связей на объектном уровне а не таблиц, а уж какой доступ не важно. Но важно что бы структура базы отвечала ООБД и ООП на стороне сервера.
S>> В том числе. Но платформа V7 объективно была нужна.
VD>Не платформа V7, а некий конструктор с пребилднутыми конфигурациями.
И псевдо ОО подходом. Далеким от настоящего, но. В итоге в 8 ке пришли к прямым запросам. S>>Но время идет а воз и ныне там (V8 улучшенная версия не более).
VD>Я про весмерку только слышал, но сам не видел. Слышал что они там клиент-сервер (трехзвенку) залудили. Но что там появилось с точки зрения разума в системе не знаю. Вот бы кто поведал...
Что то убрали , что то добавили как в язык и сделали его SQL ориентированным, так и схему БД. Добавили разделение по блокировкам в зависимости от затрагиваемых объектах. Пока народ только балуется.
Но ДБФ+TSE обгоняют SQL версию.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Я про весмерку только слышал, но сам не видел. Слышал что они там клиент-сервер (трехзвенку) залудили. Но что там появилось с точки зрения разума в системе не знаю. Вот бы кто поведал...
Здравствуйте, Serginio1, Вы писали:
S> Возьми мой пример иерархической БД и сравни если хочешь. Самому очень интересно. Или пришли свои таблицы, а с ними поработаю с прямым доступом без индексов, или построением своих индексов или хэш-таблиц с учетом этого времени.
Например, можно взять из той статьи. Там и скрипт для базы и запрос суровый есть.
S> Но уверяю, что прямой доступ с ранним связыванием будет всегда быстрее.
SQL-сервер написан на С++ и очень грамотными программистами. Так что вряд ли у них скорость будет ниже. Им как минимум не нуно будет данные конвертировать из строк, да и хранние с кэшированием оптимальнее.
S> А я не один раз так как иногда захожу на 1С форумы. Диски летят.
Прчем здесь диски? На то райды есть. Ты найди упоменание о слетании БД от резета или по вине SQL-сервера.
S> Ну акто запрещает сделать это самому???? При чем я не сторонник РБД а уж DBF тем более.
Да никто не мешает и ОС свою залудить. Вот только жаль жизнь коротка. Да и скил твой (и мой) вряд ли выше чем у тех кто SQL-серверы проектирует и реализует.
S>Нужно делать специально заточенную базу ИМХО.
По до что?
S> ОО Надстройку можно делать над чем угодно, главное грамотно создать и прописать метаданные (схему бд и связей на объектном уровне а не таблиц, а уж какой доступ не важно. Но важно что бы структура базы отвечала ООБД и ООП на стороне сервера.
Вот ты не в восторге от РСУБД, а я как-то не фанат ОО. ОО иногда полезно, а иногда не очень. Для хранения и передачи данных ОО, по-моему, подходит плохо. Так что обертки делать можно, но хранить нужно как-то по другому.
S> И псевдо ОО подходом. Далеким от настоящего, но. В итоге в 8 ке пришли к прямым запросам.
Да плевать мне на 8-ку и вообще на 1С. У меня вроде как есть видение как это сделать довольно производительно и красиво.
S> Но ДБФ+TSE обгоняют SQL версию.
Дык ты попробуй нормально написанную обгони. 1С то и дурак обгонит.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Я про весмерку только слышал, но сам не видел. Слышал что они там клиент-сервер (трехзвенку) залудили. Но что там появилось с точки зрения разума в системе не знаю. Вот бы кто поведал...
AVK>Я тебе как то рассказывал.
Ну, это отрывочная информация. К тому же я так понял, ты и сам с ней серьезно не разбирался. Интересно послушать человека который ее прорыл в доль и поперек.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Возьми мой пример иерархической БД и сравни если хочешь. Самому очень интересно. Или пришли свои таблицы, а с ними поработаю с прямым доступом без индексов, или построением своих индексов или хэш-таблиц с учетом этого времени.
VD>Например, можно взять из той статьи. Там и скрипт для базы и запрос суровый есть.
S>> Но уверяю, что прямой доступ с ранним связыванием будет всегда быстрее.
VD>SQL-сервер написан на С++ и очень грамотными программистами. Так что вряд ли у них скорость будет ниже. Им как минимум не нуно будет данные конвертировать из строк, да и хранние с кэшированием оптимальнее.
Но позднее связывание. И оптимизатор как бы его не нахваливали, все равно подтормаживает и не всегда выбирает нужный план.
Набирать статистику смысл, особенно когда она может сильно меняться???
S>> А я не один раз так как иногда захожу на 1С форумы. Диски летят.
VD>Прчем здесь диски? На то райды есть. Ты найди упоменание о слетании БД от резета или по вине SQL-сервера.
И раиды тоже. S>> Ну акто запрещает сделать это самому???? При чем я не сторонник РБД а уж DBF тем более.
VD>Да никто не мешает и ОС свою залудить. Вот только жаль жизнь коротка. Да и скил твой (и мой) вряд ли выше чем у тех кто SQL-серверы проектирует и реализует.
Да на самом деле ты немного преувеличиваешь сложность. Тем более когда наработок куча и в свободном ПО.
Но малобюджетные локальные РБД не представляют особой сложности. Но они нужны. Не всем же на Оракулах работать. S>>Нужно делать специально заточенную базу ИМХО.
VD>По до что?
Под определенные задачи учета и хранения данных. Там, где SQL сервера не нужны.
А так же лицензии. Почему в интернете бесплатные БД??? А MySQL до недавнего времени вообще без транзакций работал. S>> ОО Надстройку можно делать над чем угодно, главное грамотно создать и прописать метаданные (схему бд и связей на объектном уровне а не таблиц, а уж какой доступ не важно. Но важно что бы структура базы отвечала ООБД и ООП на стороне сервера.
VD>Вот ты не в восторге от РСУБД, а я как-то не фанат ОО. ОО иногда полезно, а иногда не очень. Для хранения и передачи данных ОО, по-моему, подходит плохо. Так что обертки делать можно, но хранить нужно как-то по другому.
Вот вот. Я не противник РСУБД, я за различные подходы хранения данных и связей и здесь должны существовать различные механизмы, а не жесткие как в РБД.
Если немного пофантазировать то хранение объектов в памяти мало отличается от их хранения в БД. Сделать свой менеджер памяти для БД а при загрузке БД в файл маппинг корректировать доступ к объектам через кооректировку путем ссумирования адреса и базового адреса загрузки и запоминать измененные страницы через свойства, а можно и без этого если сразу загружать с определенного адреса. Интересно, а зачем нужно для БД задавать намного больший размер???? (не дефрагментация диска)
Но это так детский лепет, хотя 64 разрядные процессоры действительно позволяют это делать без проблем из-за огромного диапазона адресов. И имеем настоящую ООБД. Эх мечты.
Правда изменение структур данных итд, но и это решаемо. И вот здесь уж точно SQL обгоню без вопросов. VD>Да плевать мне на 8-ку и вообще на 1С. У меня вроде как есть видение как это сделать довольно производительно и красиво.
Поделился бы. Очень интересно. Или статью написал бы. По некоторым оценкам написание аналога 1С порядка 200 кб без рекламы. S>> Но ДБФ+TSE обгоняют SQL версию.
VD>Дык ты попробуй нормально написанную обгони. 1С то и дурак обгонит.
Но выбирают ее. И мне если честно плевать на нее.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Но позднее связывание.
Позднее связывание тут вообщен не причем.
S> И оптимизатор как бы его не нахваливали, все равно подтормаживает и не всегда выбирает нужный план.
На то есть хинты.
S>Набирать статистику смысл, особенно когда она может сильно меняться???
Изсенится — будет другие результаты.
S> И раиды тоже.
Это из серии сказок. Вероятность один к миллиону.
S> Да на самом деле ты немного преувеличиваешь сложность. Тем более когда наработок куча и в свободном ПО. S> Но малобюджетные локальные РБД не представляют особой сложности. Но они нужны. Не всем же на Оракулах работать.
Дык МСДЕ и есть малобджетная локальная СУБД. Только качественная.
S> Под определенные задачи учета и хранения данных. Там, где SQL сервера не нужны.
И будешь изобратать, то что давно изобретено. В общем... велосипед.
S>А так же лицензии. Почему в интернете бесплатные БД??? S>А MySQL до недавнего времени вообще без транзакций работал.
Это его проблемы.
S> Вот вот. Я не противник РСУБД, я за различные подходы хранения данных и связей и здесь должны существовать различные механизмы, а не жесткие как в РБД.
Проблема в том, что хранение и обработка данных — это огромная задача. И эта задача уже сделана на высоком проффесиональном уровне. Так зачем ее делать еще раз (и возможно хуже)?
S> Если немного пофантазировать то хранение объектов в памяти мало отличается от их хранения в БД.
Это если очень поверхностно фантазировать.
S> Сделать свой менеджер памяти для БД а при загрузке БД в файл маппинг корректировать доступ к объектам через кооректировку путем ссумирования адреса и базового адреса загрузки и запоминать измененные страницы через свойства, а можно и без этого если сразу загружать с определенного адреса.
И останется реализовать:
1. Уровни изоляции.
2. Надежность.
3. Транзакции.
4. Кэширование.
5. Энжин запросов.
6. Систему индексации и навигации по индексам.
S> Интересно, а зачем нужно для БД задавать намного больший размер???? (не дефрагментация диска) S> Но это так детский лепет, хотя 64 разрядные процессоры действительно позволяют это делать без проблем из-за огромного диапазона адресов. И имеем настоящую ООБД. Эх мечты.
Настоящие ООБД тоже есть. Зачем их вручную делать? Ну, или тогда нужно заниматься исключительно ООБД.
S> Правда изменение структур данных итд, но и это решаемо.
Все решаемо. Вот только жизнь конечна и скоротечна .
S> И вот здесь уж точно SQL обгоню без вопросов.
Не факт. SQL, а вернее современные реляционные СУБД очень хорошо спроектированны и реализованы. Достичь того же уровня фичь при той же производительности будет не просто (и уж точно не быстро).
S> Поделился бы. Очень интересно. Или статью написал бы. По некоторым оценкам написание аналога 1С порядка 200 кб без рекламы.
Можно индексированные.
.