kolobok0
Вы уважаемый сами се противоречите. Уже прозвучала мысль - либо туды...Либо сюды... То Вы за раз проглатываете все данные для обработки на клиенте. То Вы не собираетесь гнать гигабиты... Вы уж определитесь батенька... Либо Вы показываете на клиенте от балды ? Что не попадя ? Или всё таки грузите инфу, со всякими пользовательскими прижимами, подсветкой если бла-бла-бла формулой, динамической сортировкой, динамическими филдами из той же базы - менющиеся от одного до штук эннн ?.


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

kolobok0
я ПОЛНОСТЬЮ согласен с ПРАВИЛЬНЫМ взглядом на весчи по поводу обработки получаемых данных. Если человек - то не очень много, это и понятно. Если отчёт - то так же. Но простите - это ВЫ ПРЕДЛАГАЕТЕ ГНАТЬ ВСЁ НА КЛИЕНТА !!!

С каких это пирогов? Все не надо, только то что закзал клиент.

kolobok0
По поводу изменения картинки - знаете Вы глубоко ошибаетесь. Очень часто нужно в режиме ОН ЛАЙН видеть динамические изменения. Или скажем по другому - сколько часов хранения выбранной информации, Вы считаете эту информацию ликвидной ? Час, неделя, месяц ? Я сильно не завидую тем пользователям в работу которых введена временная составляющая влияющая на результат работы...


Причем тут час, месяц? Клиент сам решает когда он хочет обновить данные.
И если он изучает статическую информацию, пытаться ему втюхать свежую-зачем?
Тут ключевое слово, когда это нужно делать, а когда нет. Для обычных учетных торговых систем это нужно? зачем? в каких случаях?

kolobok0
Низкая проивзодительность это менее секунды ?


Вот тут я чтото не понял. Менее секунды как раз нормальная
производительность. Только не видел я таковой у существующих "крутых" ERP-системах.

kolobok0
На нескольких десятках таблиц, с несколько киллобайтными диннамическими запросами, динамически добавляемыми пользователем полями и любой сортировки (и правил сортировки кстати) по любому полю либо комбинации полей ? Хочу, Хочу взглянуть на такую систему например на MSSQL.


Их есть у меня:) И именно на MS SQL.
Только вот никак не врублюсь, зачем пользователю самому заводить поля в БД? Если по уму, это делается немного по другому...

kolobok0
То, что я предлагаю - это жизненная логика, обкатанная не на одном продукте между прочим. И именно оптимизация обьёма передаваемых данных -лежит в углу данной логики. Это передача на клиента именно НЕОБХОДИМЫХ данных со всеми бантиками описанными выше. Какие курсоры ? гы... какие писки ? По поводу оракла - Вы знаете именно когда была решена задача быстрого сканирования баззы БЕЗ ИНДЕКСА, но с учётом сортировки юзверя - вот тоды я зауважал оракл. Да, в тупую начириканные сиквол запросы будут тормозить как китайцы. Да, дилетанты за пару месяцев такое не напишут. Да, это трудозатраты. Но то, что клиентами данной контент системы выступали хорошо известные зарубежные марки - говорит само за себя.


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

kolobok0
критерий "разумные ограничения" - это в чём меряется ? и "нормальная выборка" - ту да же...??


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

kolobok0
Вы предлагаете ограничить клиента ? Или предпалагаете что НЕ найдётся такой клиент который скажет - ХАЧУ ВСЁ !!! Ну ХОЧЕТ ОН ! ииии что делать в таком случае ? говорить дескать это не "нормальная выборка" ? или предлагать "разумные ограничения" ? Типа давайте щаз выдам 100 тысяч, а через пол часа ышо 200 ?

Ни в коем случае не ограничивать, хотя это тоже входит в систему прав доступа. А хачу все-это для дэбилов. Толку то от Вашего хочу все. Вы трафик посчитайте с Вашим подходом.

kolobok0
поиск по подстроке, с выдачей текущей инфы по товару (к примеру)...понятное дело - мона представить всё в тумане - дескать круто вводите сначало то, потом сё...не бум КАК можно реализовать... Скажем - ХОЧЕТЬСЯ такой функционал и точка...


Ну и какие проблемы все это есть и так. Зачем реализовывать?:)

kolobok0
Во-Во вот это мне нравится в спецах... Именно не решать задачи а пытаться завуалировать минусы того или ионого решения. В принцепе это не плохо. Но простите, не до такой же степени ! Задача очень банальна - без изменения системы иметь возможность описывать, вводить, удалять, изменять такие весчи как: имена таблиц связей, поля связей, поля показа, условия показа, способ показа, формулы показа, прижим и т.д. и т.д. и т.д...


Эта задача у Вас возникла именно потому что ядро системы спроектировано соответсвующим образом. Поэтому скорее всего и имеете Вы крупные тормоза в работе. Я в этом уверен на 200%.
И Вам даже в голову не приходит, что многие задачи Вашей системой решаются через....
И все делается гораздо проще: без изменений названий таблиц, полей и прочей лабуды. Все что Вы указали делается без допуска пользователя к структуре БД, что само по себе крутейшее нарушение режима безопасности.
В идеале, у пользователя вообще не должно быть пермишенов на таблицы, но это в идеале. А у Вас судя по всему он гуляет по БД как у себя дома.

ASCRUS
1. Может у одного клиентского места и хватит, а у множества клиентских мест точно не хватит. Плюс я думаю никто не будет рад, видя задержки при открытии форм, получении отчетов, постоянного пересоединения клиентского приложения при отвалах канала и т.д.


А нету задержек:) Просто в принципе нет. И даже когда канал отвалится, приложение само производит повторный коннект незаметно для пользователя.
Ну и потом, мы вроде уже живем в 21 веке. Нормальный выделенный инет стоит копейки. Какие проблемы то?

ASCRUS
2. Какие могут быть требования к каналу у репликации, которая может передавать данные через мыло, FTP или даже файлами (оставляя их отсылку на усмотрение клиентов) ? У меня например БД с ноутбука спокойно реплицируются через GPRS моего сотовика, висящего на поясе посредством BlueTooh, качая потихонечку через FTP. По моему не самый скоростной и стабильный канал связи.
[quot]

Ну так и у меня системка напрямую работает через мобилу(Скайлинк).

[quot ASCRUS]
3. Максимально в ASA, где необходимо "специальным образом проектировать БД" - это в таблицах организовать поле "Код узла", чтобы можно было определить область видимости информации для различных узлов, однако обычно поле "Код филиала" уже в БД и таблицах присутствует. Все остальные проблемы, в том числе с разрезом действия инкрементов, обработкой конфликтов одновременного изменения информации на разных узлах и прочее уже штатно предусмотрено в ASA, причем максимально предусмотрено так, чтобы этим было удобно и просто пользоваться. Здесь, в отличие от ASA, для некоторых других РСУБД у меня иногда возникает подозрение, что сами разработчики сервера на нем реальные рабочие БД не делали, иначе бы давно уже доделали очевидные вещи, которых явно не хватает.


А вот тут я вспоминаю Станиславского.:) Не верю. Штатные средства-это штатные средства, они про логику Вашей БД ничего не знают.
Вот и расскажите на пальцах на простом примере как это происходит(тем более что это очень легко как Вы утверждаете).
есть таблица одна и таже, на разных серверах в нее суют разные записи, которые имеют один и тот же ID. Ну и как у Вас все разрулится. Еще мне интересно какие в этом случае будут ключи+индексы. Особенно уникальные.

kolobok0
словоблудие...
я не знаю по поводу Ваших телепатических способностей - но увы и ах они Вас подкачали.
Вам рассказали решение - Вы начинаете доказывать что то.. То ли себе, то ли ышо кому... хз... Не знаю... Всяким там "вшивым" фирмам типа боинг или дэлли пресс - нравиться если покупают.
Допуск к структуре ? а это простите Вы с чего взяли ? Какие пермишен ? Это Вы к чему ? Не, ну если Вы хотите поговорить о секьюрити - могём.. Про винды пойдёт речь то ? Или про "какой нить" другой ос ? :) Могём и другое железо обсудить - всякие там SAM кристалы к примеру...


Вот мне интересно, Вы вообще на какой системе работате, на файл серверной или SQL? У меня уже сомнения, если Вы про такое слово как "Permissions" спрашиваете.
По поводу нравиться - покупают, я уже рассказывал, только Вы так это легко прошли мимо этого вопроса. Сейчас Аксапту все покупают, что хотите сказать-классная система? От нее даже программеров выворачивает, я уж молчу про пользователей.

kolobok0
но, я же Вас не гружу спамом ? почему Вы растекаетесь по древу ?


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

kolobok0
то, что Вы поменяли два раза кочку зрения - я вооще молчу :)


Эт где? :)
Вы уважаемый если на поставленный вопрос не можете ответить по существу или нечем крыть в дискуссии не перекладывайте хотя бы с больной головы на здоровую.

ASCRUS Теперь инкремент будет вести для каждой БД в своем разрезе. При выгрузке БД из консолидированной БД для удаленного подписчика этот код БД автоматически устанавливается как User_id самого подписчика и таким образом соблюдается уникальность, хотя его конечно же можно поменять на любой свой. Для консолидированной БД коды будут идти в разрезе от 1 до 100000000, для первой удаленной от 100000001 до 200000000 и т.д. Естественно если в БД вставляется запись с инкрементом, не попадающим под текущий разрез инкрементов БД, то инкремент таблицы сбиваться не будет, поэтому когда в консолидированную БД придет запись с первого узла с инкрементом 200000001 и у него последним полученным инкрементом будет значение к примеру 100, то в консолидированной БД следующая вставляемая запись получит 101, как и полагается.

Если разреза в какой либо из таблиц остается меньше 1% (то есть вот вот сработает), в БД срабатывает событие GlobalAutoincrement, в которое мы можем вписать свой код, например увеличить код БД новым значением и уведимить администраторов по почте или той же репликации через запись в табличку своих сообщений.

Ну и какие тут сложности с вставкой новых записей ? Где тут хитрости с ключами/индексами и прочяя лабуда, что нам бы пришлось делать в других РСУБД ? Так что - Станиславский говорил "Не верю", а не "Ты не похож на то, что я знаю"

Что то в этом духе я и думал. От такого подхода отказался еще лет 8 назад.проблемы наступают когда заканчиваются лимиты. А это происходит быстро. А таблиц то много. Не эстетично это.
Помнится Вы говорили про холдинг с заводами. Я примерно представляю объем тех же проводок в у средненького оптовика. И только догадываюсь сколько их будет даже у одного завода.
С условием того что операции можно проводить, перепроводить, а значит проводки могут удаляться, заново добавляться получая новые ID(они же инкременируются все новыми значениями), умаетесь интервалы менять. Я тут смотрел базку у одного из небольших клиентиков. При кол-ве проводок в 5млн. последний ID = 45227397.

Александр ГoлдунУх ты, сколько нафлеймили! :)

OTiger
А нету задержек:) Просто в принципе нет. И даже когда канал отвалится, приложение само производит повторный коннект незаметно для пользователя.

Да? Арендуете каналы транстелекома с доступностью три девятки? Канал восстанавливается незаметно для пользователя?
Даже у монстров типа МТУ, Комкора и прочих канал в Москве может исчезнуть в рабочее время на несколькой часов. А база то осталась в центральном офисе. Остатков не знаем, была ли вчера оплата - не успели посмотреть. Справочник клиентов и номенклатуры там же. Так что ТОРГ-12 выписывать придется вручную

Эт зачем, есть мобильный интернет. Тот же скайлинк.
А вообще сказки рассказываете. Даже у меня дома, за МКАДом обрывов практически не бывает. Дай бог раз в полгода на 10-20 минут.
У меня так несколько московских тех.надзоров работают удаленно. А это 10 (кол-во округов) удаленных точек регистрируют технику в онлайн режиме. И вот уже за сколько лет еще ни разу вручную ничего не оформляли.

OTiger
Ну и потом, мы вроде уже живем в 21 веке. Нормальный выделенный инет стоит копейки. Какие проблемы то?
Александр Гoлдун
За пределами МКАД тоже работают люди и используются информационные системы. И там еще очень и очень много мест, где канал стоит не копейки. И дело иногда даже не в копейках, а вообще в невозможности получить нормальный канал за любые деньги.



Я сам там живу. И канал стоит сущие копейки. Причем возможностей масса, в том числе через тарелочку, если уж совсем в лесу:)

ASCRUSДа по подмосковью только куча крупных заводов, у которых дай бог 64к на радио модеме есть. Протянуть отдельный выделенный канал с резервными линиями, да чтобы провайдер гарантировал 100% круглосуточную работу - это не хилых денег стоит и не надо свой домашний канал с промышленным сравнивать - другие условия, другие обьемы, другие требования и цены соотвествующе другие. Я уж молчу про удаленные точки, находящихся совсем не в пределах протягивания кабеля - этак 100-500 км от близжайшего населенного пункта. Тут без оффлайн репликаций, умеющих вести сеансовую работу и не требовать прямой видимости между серверами - никуда не деться.

Ну ка, раскажите мне про завод, который удален от населенного пункта на 500 км. Покажите хоть один такой на карте? Мне в принципе интересно, где люди то, работающие на нем живут? За 500 км. кажный день ездят?:)

OTiger
Эт зачем, есть мобильный интернет. Тот же скайлинк.

Александр Гoлдун
У которого надежность выше, чем, скажем, у МТУ?
OTiger
А вообще сказки рассказываете. Даже у меня дома, за МКАДом обрывов практически не бывает. Дай бог раз в полгода на 10-20 минут.

Мониторится все время? Не верю. Или там в контракте оговорены особые условия включая возмещение ущерба от отсутствия связи?


Какие особые условия? Вы что?
А у Скайлинка интернет очень даже вполне, у нас... Во всяком случае за год юзания не помню случая чтобы сбойнуло. Вот голосовой у них не фонтан, а инет вполне. А сейчас еще продвигают инет беспроводной в 2.4 мбит

OTiger
Ну и потом, мы вроде уже живем в 21 веке. Нормальный выделенный инет стоит копейки. Какие проблемы то?
Александр Гoлдун
За пределами МКАД тоже работают люди и используются информационные системы. И там еще очень и очень много мест, где канал стоит не копейки. И дело иногда даже не в копейках, а вообще в невозможности получить нормальный канал за любые деньги.

Я сам там живу. И канал стоит сущие копейки. Причем возможностей масса, в том числе через тарелочку, если уж совсем в лесу:)
Хорошо. Расширю понятие. Жизнь существует за пределами московской области. И, например, в какой-нибудь братской Беларуси есть множество мест, где со связью очень и очень плохо. При том, что в этих местах есть люди, производства и т.п. А если решишь потратить несколько десятков тысяч зеленых на двунаправленный спутниковый канал, то батька пришлет в людей форме, ибо нельзя. А там, где все-таки есть какие-то каналы, стоят они совсем не копейки, а например около $500 в месяц за 128 кбит, но при этом белорусские 128 кбит отличаются от российских как белорусский рубль от российского рубля.


А, понимаю, наверное совсем не парочка тысяч $ за обслуживание монстров от ERP видимо для Вас дешвле. Тогда ой...

Александр Гoлдун
Так что не надо рассказывать сказки про сущие копейки и 21 век, если не владеешь достоверной информацией.

Вы мне тогда про МКАД не рассказывайте. Вы еще эфиопию в пример приведите. От МКАДа еще дальше тянуть придется.
Я ж не виноват что в Белоруссии такие цены драконовские.