Так елементарна річ на зразок select * from table1, table2 дає декартовий продукт на виході. Як це виглядає у 1С вибач, не знаю.
всё сдаюся шо оно с таблицами делает я давно понял, а зачем - я не понял Какую задачу человеческим языком програмеру ставят?
Так отож.
Так получилось. И работает Переделывал раза 4 с ноля пока получилось
еще об альтернативах...
я конечно могу сейчас обложиться книжками по БД и делфям (благо базовые знания по БД есть, а уровень вчерашних-студентов-делфистов я настигну очень бысто, потому как в свое время на паскале ваяли довольно взрослые вещи (хоть и не из области учета), на сях быстро не смогу конечно) взять какой-нибудь бесплатный толковый sql... бухучет сам не потяну, но достаточно универсальный "склад" сделать смогу сам или с парой товарищей и дописывать потом и сопровождать смогём и даже впарю его сходу полсотне клиентов, которые просто на доверии мне согласятся...
У такому разі дельфі не кращий вибір. Яка небудь жаба значно краще підходить для таких задач.
а смысл? забить на собственное благосостояние и заняться светлым будующим?1С решит мои задачи быстрее и проще, а на серьезную конкуренцию нет ни знаний, ни ресурсов, и просто бабла...
Скоріше зайнятися власним світлим майбутнім А знання... знання ніколи лишніми не бувають.
так что выбираем потребительскую позицию
Я вже писав, що кожен сам робить свій вибір.
Так елементарна річ на зразок select * from table1, table2 дає декартовий продукт на виході. Як це виглядає у 1С вибач, не знаю.
всё сдаюся шо оно с таблицами делает я давно понял, а зачем - я не понял Какую задачу человеческим языком програмеру ставят?
Так у тому-то і справа, що формально така операція виникає завжди при обробці запиту. Все, що потім у where пишеться, використовується для фільтрації кортежів які попадають у таблицю-результ. Для того щоб цього уникнути і потрібна оптимізація, наприклад where table1.field = table2.field дає можливість об'єднувати використовуючи індекси чи проміжні хеш-таблиці (це самі прості варіанти). Звичайно, навіть у найгіршому випадку сервер не будує проміжний декартовий продукт повністю, а робить це порціями, фільтруючи потім кожну порцію. Але то сервер, у нього є доступ до всього і контроль над виконанням операції. У "ручному" режимі так не вийде, треба мати повну проміжну таблицю, тому я і здивувався, коли ти зібрався робити це руками.
Це від незвичності. Насправді "порядку" досить легко досягти. Береш один дистрибутив із мейнстрімних і маєш "порядок" як у віндах.
Провокационный вопрос. Какой дистрибутив рекомендуешь для домашнего изучения, офисного использования? Так чтобы всякие флешки-кардридеры и USB принтеры понимал, ИК-порт USB. Где драйвера брать? Где у этих зараз частота монитора меняется? Желательно документированный максимально "для дебилов".
Візьми SuSe. Все є в комплекті. Частота монітору змінюється через ControlCenter (це така програма для настроювання всіх параметрів системи, від кольорів і тем гуя до залізяк і юзерів і таке інше). Після вінди тобі повинно бути досить звично.
Можно ли сваять вариант: сервер с виндовыми приложениями (та же 1с например), а клиенты под линухом в режиме терминала.
Я бачив термінального клієнта для вінди на жабі, але він не безкоштовний. Можливо є і інші варіанти, я не цікавився.
Візьми SuSe. Все є в комплекті. Частота монітору змінюється через ControlCenter (це така програма для настроювання всіх параметрів системи, від кольорів і тем гуя до залізяк і юзерів і таке інше). Після вінди тобі повинно бути досить звично.
ну я б наверное все-таки мандрейк порекомендовал. у сусе из коробки нет руссификации. или уже появилась ?
Візьми SuSe. Все є в комплекті. Частота монітору змінюється через ControlCenter (це така програма для настроювання всіх параметрів системи, від кольорів і тем гуя до залізяк і юзерів і таке інше). Після вінди тобі повинно бути досить звично.
ну я б наверное все-таки мандрейк порекомендовал. у сусе из коробки нет руссификации. или уже появилась ?
Не знаю, коли її там не було, бо до 9.1 я не дивився, а у 9.1+ з інтернаціоналізацією все у порядку.
особенно посмотрев, как это делается у мерикосов - ч/б текстовый интерфейс, тетка лупит по кнопкам практически не глядя + кардридер в клавиатурею с карты деньги удетают быстрее, чем у нас успевают в карман полезть. и никаких дурацких виндов, мышек и пос-терминалов
в караване был? сильно на кассе мышкали? сильно задержали тебя виндой и гуем?
ага. был. простоял полчаса в очереди - "звыняйте, мы карточки не принимаем" был и в фуршете и в мегамаркете с финсэкспертами на виндах а к чему ты это?
Так у тому-то і справа, що формально така операція виникає завжди при обробці запиту. Все, що потім у where пишеться, використовується для фільтрації кортежів які попадають у таблицю-результ. Для того щоб цього уникнути і потрібна оптимізація, наприклад where table1.field = table2.field дає можливість об'єднувати використовуючи індекси чи проміжні хеш-таблиці (це самі прості варіанти). Звичайно, навіть у найгіршому випадку сервер не будує проміжний декартовий продукт повністю, а робить це порціями, фільтруючи потім кожну порцію. Але то сервер, у нього є доступ до всього і контроль над виконанням операції. У "ручному" режимі так не вийде, треба мати повну проміжну таблицю, тому я і здивувався, коли ти зібрався робити це руками.
усё, наконец понял даже не знаю как это реализовано в 1с - могу только субъективно на пальцах попробовать
дбф 1с 7.7 как движку БД использует codebase "внутренний язык" 1с позволяет делать выборки двумя вариантами - "тупой перебор таблиц" и "режим запросов" так вот производительность в дбф-варианте по ощущениям практически одинаковая в двух случаях а вот в sql-варианте 1с запросы начинают "летать" те отчеты, которые в дбф-вариантке написаны шо путем запроса шо путем тупой выборки могут формироваться несколько часов, а то и вообще подвиснуть в sql они формируются за несколько секунд-минут правда опять же - сам запрос проходит быстро, а затормаживает процесс последний этап "прорисовки отчета" он выполняется на клиентской машине и если отчет в пару строк, но со сложной выборкой - sql вариант 1с + отчет через запрос радует всех до писка а вот если в отчете в результате полсотни тысяч строк сам запрос проходит за считанные пару минут вместо пары часов на дбф, а потом еще минут 10-20 малюется сама картинка проследить просто, если в тексте модуля отчета - проставить метки и проследить производительность каждого этапа
в стандартных поставках 1с запросы используются практически только в отчетах, правда в последнее всемя всё больше их используют и при заполнении документов, проведении и т.д. поэтому субъективно кажется что при переводе 1с под sql "летать" начинают только "тяжелые" отчеты, а скорость остальной работы почти не меняется ну и получается максимально-возможная переделка быз 1с с использованием запросов вместо тупых выборок - это как вариант выхода из положения так шо не всё так плохо
еще момент скорость конечной "прорисовки отчета", особенно очень длинного в десятки-сотни страниц сильно зависит от мощи клиентской машины и если клиент - чахлый целерон 300-400 с набортовой видяхой в 2 метра лично меня очень утомляет видеть как запрос формируется пару секунд, а потом мы 3-4 минуты ждем пока нарисуется красивая картинка на "гуе" тут выход конечно - терминал, но это не всегда удобно и возможно а как это происходит у "правильных" софтин?
ага. был. простоял полчаса в очереди - "звыняйте, мы карточки не принимаем" был и в фуршете и в мегамаркете с финсэкспертами на виндах а к чему ты это?
к тому, что я не вижу затормозки процесса и мышканья на гуи в супермаркетах
Не знаю, коли її там не було, бо до 9.1 я не дивився, а у 9.1+ з інтернаціоналізацією все у порядку.
кстати покопался на тему учетных программ под линух http://1l.w4b.ru/ - пытаются сделать натуральную 1с под линух с поддержкой существующих баз пока с их темпом похоже что раньше или шах помрет или ишак
http://ananas.lrn.ru интересная игрушка - качнул, поигрался убогая конечно и глючная пока, но налицо тупой закос под 1с, хотя и линукс и mysql такого плана и будут "правильные" разработки, если будут серьезные будет правильный движок, но жесткий закос под 1с во всем остальном, возможно будут оличия и в языке и интерфейсе, но идея будет та же - слишком сладкая перспектива загрести под себя всю толпу 1с-ников - готовых спецов по внедрению с клиентской базой (хороших или плохих - другой вопрос) так что, спи спокойн - дорогой товарищ 1с-ник!
еще смотрел какусь винницкую софтину бухучета под линух - реально шопопало конечно, но может пока...
дбф 1с 7.7 как движку БД использует codebase
Ух. Я останній раз балувався написанням sql subset мови запитів з codebase у якості DB engine році у 95-му До речі, для своїх задач працювало дуже непогано, але такий підхід вимагає наявності індексів для всіх полів по яким робиться об'єднання, інакше не працює codebase-вський bitengine. Зробити підтримку повного декартового продукту можна, але повзати воно буде як черепаха...
еще момент скорость конечной "прорисовки отчета", особенно очень длинного в десятки-сотни страниц сильно зависит от мощи клиентской машины и если клиент - чахлый целерон 300-400 с набортовой видяхой в 2 метра лично меня очень утомляет видеть как запрос формируется пару секунд, а потом мы 3-4 минуты ждем пока нарисуется красивая картинка на "гуе" тут выход конечно - терминал, но это не всегда удобно и возможно а как это происходит у "правильных" софтин?
Проблема інтерфейсу є всюди. Вирішується дизайном інтерфесу коли за винятком дуже крайньої необхідності на екран більше декількох рядків з бази не виводится.
Не знаю, коли її там не було, бо до 9.1 я не дивився, а у 9.1+ з інтернаціоналізацією все у порядку.
Я вже хотів порекомендувати цей сайт Бери "просто", не промажеш. x86_64 має сенс тільки якщо є багато програм які краще працюють на атлонах і пеньках з 64-бітним розширенням.
так что, спи спокойн - дорогой товарищ 1с-ник!
Спробуй пошукати ERP під лінух.
Ух. Я останній раз балувався написанням sql subset мови запитів з codebase у якості DB engine році у 95-му До речі, для своїх задач працювало дуже непогано, але такий підхід вимагає наявності індексів для всіх полів по яким робиться об'єднання, інакше не працює codebase-вський bitengine. Зробити підтримку повного декартового продукту можна, але повзати воно буде як черепаха...
ну так 6.0 как раз тогда и вышла, т.е. разрабатывалась еще раньше 7.7 получила в наследство тот же двиг по неизвестной причине (обсуждали ужо) а 7.7 sql - попыталась исправить ошибку, но полноценно сделать клиент-сервер видать не вышло, т.к. сильно много завязано на старое наследство а 8.0 уже полноценный клиент-сервер, еще и с какими-то заморочками типа основой сервер - мс-скуль, а дополнительные - промежуточные: какая-то хрень под названием "сервер 1с предприятия 8.0" я пока не разбирался есть варианты 8.0 которые не используют мс-скуль, а только какой-то свой "сервер" - говорят тоже вариация sql только в этом 8.0 столько цветастых рюшечек и прочих полуненужных наворотов (типа встроенного почтового клиента, веб-сервера и т.д.), что оно у меня дома (на П-3 550 256 мозгов) еле чёвгает
Проблема інтерфейсу є всюди. Вирішується дизайном інтерфесу коли за винятком дуже крайньої необхідності на екран більше декількох рядків з бази не виводится.
значит прально делаю, что максимально упрощаю формочки
Я вже хотів порекомендувати цей сайт Бери "просто", не промажеш. x86_64 має сенс тільки якщо є багато програм які краще працюють на атлонах і пеньках з 64-бітним розширенням.
"просто" на cd у них нет, меня ломает двд хороший (гамно ж себе не будешь ) покупать чтобы линух попробовать i386 для пней 2-3-4, целеронов, семпронов пойдеть?
Спробуй пошукати ERP під лінух.
буржуйских видел немало ссылок, не качал нам местного разлива нада бухгалтера и манагеры аглицкий не бельмесают
мы тут вроде как спорим о потребностях и возможностях автоматизации учета на малых и средних предприятиях
Причем тут оракл - я его упомянул хоть раз? Все умные задним числом. Как надо было делать. Можешь у Нуралиева спросить - почему он не сделал. Я не знаю. А ты возьми и сделай. Шуструю, со встроенным языком, с бухгалтерией и без заоблачных цен и сопровождай её. Я уже сколько раз в этой теме просил показать пальцем реального конкурента. Или хотя б фирму на которой реально работает софтина-конкурент 1с и люди реально довольны. И чтобы она была функционально лучше 1с.
мы говорили о способах повышения производительности систем бухучета. а вы? заплати, я напишу да, я опоздал, поэтому и не пишу, да и занимаюсь я сейчас совсем другим. бухучеты меня интересуют только когдя я книгу прихода-расхода заполняю кстати, в плане "жуткой" популярности можем еще поговорить и про методы "внедрения" 1с. с лобиррованием через налоговую и пр. методы ведения "честного" бизнеса
зато все пищат про корявость 1с, но спрыгивать реально некуда. замкнутый круг.
заплати, я напишу
заплати - так и я напишу
кстати, в плане "жуткой" популярности можем еще поговорить и про методы "внедрения" 1с. с лобиррованием через налоговую и пр. методы ведения "честного" бизнеса
а мы уже поговорили
зато все пищат про корявость 1с, но спрыгивать реально некуда. замкнутый круг.
патамуша у всех подход - "заплати - напишу" а написать чтобы потом поднять денюх - у всех кишка тонка
Я вже хотів порекомендувати цей сайт Бери "просто", не промажеш. x86_64 має сенс тільки якщо є багато програм які краще працюють на атлонах і пеньках з 64-бітним розширенням.
"просто" на cd у них нет, меня ломает двд хороший (гамно ж себе не будешь ) покупать чтобы линух попробовать i386 для пней 2-3-4, целеронов, семпронов пойдеть?
Звичайно. Це не вимога до процесора, а лише режим компіляції з яким збирається ядро і софт. До речі, "просто на CD" 10-ку я у них купив, може ти не там дивився?
Спробуй пошукати ERP під лінух.
буржуйских видел немало ссылок, не качал нам местного разлива нада бухгалтера и манагеры аглицкий не бельмесают
Зовсім не обов'язково потрібен саме місцевий розлив. До того ж у грамотно зробленій системі локалізацію зробити не так складно. В усякому разі це менш витратно, ніж з нуля робити всю інфраструктуру.
Звичайно. Це не вимога до процесора, а лише режим компіляції з яким збирається ядро і софт. До речі, "просто на CD" 10-ку я у них купив, може ти не там дивився?
и385 на cd там есть
Зовсім не обов'язково потрібен саме місцевий розлив. До того ж у грамотно зробленій системі локалізацію зробити не так складно. В усякому разі це менш витратно, ніж з нуля робити всю інфраструктуру.
опять упираемся не только в локализацию, но и в бухгалтерию и поддержку обновлений отчетности - их сам рисовать каждый месяц заколебаешься
Зовсім не обов'язково потрібен саме місцевий розлив. До того ж у грамотно зробленій системі локалізацію зробити не так складно. В усякому разі це менш витратно, ніж з нуля робити всю інфраструктуру.
опять упираемся не только в локализацию, но и в бухгалтерию и поддержку обновлений отчетности - их сам рисовать каждый месяц заколебаешься
Я не казав, що там є повністю готові системи (під наш облік, я маю на увазі). До того ж, бухгалтерія там в якомусь вигляді є, хоч, звичайно, доробляти їх доведеться. Щодо оновлень форм звітів, то я не готовий дати рецепт.
Щодо оновлень форм звітів, то я не готовий дати рецепт.
Я готов дать рецепт! Взорвать пенсионный и налоговую нах
что до этих EPR-софтин под линукс -может знаешь? в каких-то из них есть "внутренний язык" или только исходники на "правильных языках"?
Просто это очень нужно, т.к. между разработчиком и конечным пользователем должно быть звено (типа тупых 1с-ников, которые будут продавать, заниматься "внедрёжем", лашить юзверей и разработчиков и т.д.) Ибо разработчик заколебается общаться с конечным потребителем - у него здоровья на них всех не хватит
Відповісти
Поперед.
Зміст
Наступ.
Гілками
шо оно с таблицами делает я давно понял, а зачем - я не понял 
А знання... знання ніколи лишніми не бувають.
