Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.06.14;
Скачать: [xml.tar.bz2];

Вниз

подсчёт кол-во в складской программе   Найти похожие ветки 

 
@k@DElpher   (2005-04-22 20:00) [0]

Здравствуйте,
пишу программу по учёту склада(ну и остального:))
есть две таблицы Парадокса:
покупки, продажи
структуры почти одинаковые:
ID(ключ),IDDoc-номер,как документа, имя документа(накладная №3),
GOODID- номер товара из таблицы товаров,Amount -Кол-во и так далее...
Как вы заметили здесь даны не документы, а товары со свойствами на принадлежность к одному документу(IDDoc).
Так вот мне надо так подсчитывать суммы, чтоб оно относилось к одному документу, и выводить это юзеру, как таблицу накладных с суммами, и например остатки по этим таблицам...
в общем там разберусь- главное, что использовать? Куда думать:)? У кого подглядеть?
или, если, кто знает - где взять примеры, и где почитать касательно именно этой темы(разработки бухгалтерских и складских программ на Delphi...
( писать буду на Delphi 2005:) )
    Заранее благодарен:)...


 
DSKalugin ©   (2005-04-22 21:52) [1]

Надо сделать
отчет с группировкой по номеру документа
В делфи6 встроена система отчетов QReport, в Д2005 - без понятия

в каждой группе обнулять "S"
суммировать цены "S":="S" + цена * колво;
и печатать "S"


 
GanibalLector ©   (2005-04-23 01:57) [2]

> писать буду на Delphi 2005
> есть две таблицы Парадокса

Однако ;) Вот уж удивили!


 
GanibalLector ©   (2005-04-23 02:00) [3]

Что-же касается сабжа,то рекомендую скачать дайджесты этого форума.И внимательно читать посты msgans.


 
@k@DElpher   (2005-04-23 02:39) [4]

to GanibalLector:
Наверное:), но просто систему в действии увидеть охота.... Что касается тормозов- не будем обращать внимания:-D...
А qReport это случайно не, как FastReport...


 
@k@DElpher   (2005-04-23 02:43) [5]

QReport в D7 это Rave?


 
@k@DElpher   (2005-04-23 06:44) [6]

В общем QReport- это такие же отчёты, как и FastReport(Вроде)...
А можно ли сделать так, чтоб сгруппированые значения выводились не в таком виде(отчёта), а в DBGrid?


 
ЮЮ ©   (2005-04-23 07:05) [7]

Можно, для этого написать запрос такой, чтобы возвращались данные в нужном виде, т.к. DBGrid предназначен для показа TDataSet-a.

Если получить данные в нужном виде не получается, то можно полученные данные уже на клиенте "записать" в виртуальный DataSet (TClientDataSet, TRxMemoryData, etc) и уже его отобразить в DBGrid


 
@k@DElpher   (2005-04-26 19:26) [8]

В общем я подумал, и решил, что так много мороки:)...
И решил использовать дргой способ... точнее 2(не могу определиться)
1) Две таблицы: покупки и продажи+ ещё две(для документов):
Когда делаем накадную, то все товары добавляются в покупки и плюс  эта накладнаядобавляется в реестр...
      Накладные          Реализации
          |                   |
    Купленные товары    проданные товары
            \\              //
           (Вывод информации)
Плюсы такой структуры:
Избавились от проблемыгруппировки в дркументы
Минусы:
Но самое главное  программе- это возможность покаывать ОСТАТКИ.
И я не знаю на сколько сложно группировать товары из двух таблиц в одну...
2)1 таблица всех товаров, при чём у них есть свойство куплен или реализован.... При добавлении, всё пихается в одну таблицу и плюс  документ прописывается в соответствующей таблицы(реестре):
            ТОВАРЫ
            /      \           /здесль не совсем сязь- это необ         Купленные  Реализованные /ходимо только для вывода ИНФЫ
               ||              /И нормального отображения                        ||              /товаров в докумете
               ||      /Вывод информации идёт прямо из товаров
           (ОСТАТКИ)  
Плюсы:
Удобно выодить остатки
Минусы:
вдруг мне ещё что-то понадобиться:)  И Чтоб во время запроса всё было нормально прийдётся в кол-во для продаж ставить МиНУС?

Если сталкивались с этой проблемой, Помогите пожалуйста:)...


 
Polevi ©   (2005-04-27 09:13) [9]

select goodid, sum(qty) from
(
select goodid, qty as qty from приходы
union all
select goodid, -qty as qty from расходы
) t
group by goodid


 
Polevi ©   (2005-04-27 09:14) [10]

а вообще зря ты связался с парадоксом
прошлый век


 
msguns ©   (2005-04-27 09:43) [11]

>@k@DElpher   (26.04.05 19:26) [8]

Мрак..


 
Sergey13 ©   (2005-04-27 09:46) [12]

2[11] msguns ©   (27.04.05 09:43)
Ну вот. Я 3 дня ждал, что ты с лекцией выступишь по этому вопросу как всегда.
А ты кратенько так. Но емко. 8-)


 
@k@DElpher   (2005-04-28 02:31) [13]

тогда на чём это круче сделать(и лучше, чтоб быстрее изучить:))


 
Sergey13 ©   (2005-04-28 09:14) [14]

2 [13] @k@DElpher   (28.04.05 02:31)
Вопрос не на чем, а как.


 
ANB ©   (2005-04-28 09:14) [15]

Oracle 9


 
msguns ©   (2005-04-28 09:18) [16]

DB2


 
ANB ©   (2005-04-28 09:20) [17]


> msguns ©   (28.04.05 09:18) [16]
- Oracle круче !!!!


 
Anatoly Podgoretsky ©   (2005-04-28 09:20) [18]

Хранить деньги в Парадоксе, останешься без денег.


 
ANB ©   (2005-04-28 09:28) [19]


> Anatoly Podgoretsky ©   (28.04.05 09:20) [18]
- с BTriev работать не приходилось ?


 
Johnmen ©   (2005-04-28 09:32) [20]

Круче только яйца. На них и делай.


 
@k@DElpher   (2005-04-28 13:17) [21]

Ни чего не остаётся, как послушать последнее сообщение:)...
Oracle- это сильно сложно:)?... Просто по идеи я в БД начинающий... И вообще самоучка. Потому что ещё школу не закончил:). Так что где-то знаю много где-то не знаю:)... Ладно попробуем с пародоксом и изучим оракл...


 
@k@DElpher   (2005-04-28 13:23) [22]

ANB, Нет не работал
А где почитать про Orcle в Delphi?


 
Sergey13 ©   (2005-04-28 13:24) [23]

2[21] @k@DElpher   (28.04.05 13:17)
Еще раз повторю - основная твоя ошибка не выборе БД (хотя Парадокс это не самый лучший выбор однозначно), а в проектировании БД. Твоя схема и на Оракле будет плохой.
Полазай поиском тут и вообще в инете. Склад не раз обсуждался.


 
Sergey13 ©   (2005-04-28 13:26) [24]

2[22] @k@DElpher   (28.04.05 13:23)
>А где почитать про Orcle в Delphi?
Его в нем нет, как и Парадокса. 8-)


 
msguns ©   (2005-04-28 13:43) [25]

>@k@DElpher  

Ты пойми, дело совсем не в базе. То, что ты наваял в [8] можно сделать хоть в обычных текстовыъх файлах хоть в оракле, хоть в хренакле,- оно не будет работать. Никогда. Потому что не может. В принципе. Как не может летать самолет без крыльев и двигателя. Разве что с обрыва ;)))

Ну почитай же дайджесты. Хотя бы ознакомься с такими понятиями, как "Карточка", "Номенклатурник", "Группы товара", "Счет", "Оплата", "Сальдо", "Прайс-лист", "Заявка", "FIFO" и т.д.
А еще лучше, посмотри как сделан 1С. Хотя бы меню и вид документов.

Ну хватит же строить из себя воинствующее невежество-то


 
@k@DElpher   (2005-04-28 17:37) [26]

Работать будет:)
в 1С сам работаю(я её отцу в фирме запускаю)(почему я- потому, что жиё далеко и тут специалистов ВООбще нет!).
Эту прогу пишу, потому что у нас точка в соседнем посёлке есть(магазин)(мы запчастями торгуем), и надо чтоб они у себя учёт  вели... Ну в общем для того чтоб, когда это у нас это появлялось можно было разные запросы делать... Почему не 1С? Да потому что- во первых запустить, во вторых обучить, в третьих нужен только склад и приход расход...
Так что над структурой я долго думал, и из 1С многое уяснил(хотя бы концепцию справочников)... И думаю заработать она 100% заработает.
 В общем решил так "Документы" буду хранить в одной таблице(с свой-вами на их вид), товары в другой...Добавлять и удалять синхронно... Ну и + все причиндалы типа справочника фирм, товаров, ед.изм., цен...
Конечно "Документы буду хранить в одной таблице" это не совсем правильно, но мне документов, то нужно!:)...
Я уже писал програмку Дебет/Кредит и органайзер статей- и с этим тоже справимся:)... Вобщем РАССКАЖУ(Сдулся или нет;))


 
ANB ©   (2005-04-29 10:38) [27]


> @k@DElpher   (28.04.05 17:37) [26]
- ты крут. Хм. Я сам в 22 первый раз сел склад писать. Тогда еще прог не хватало, инета не было, про SQL знали только самые продвинутые и сервер надыбать было не реально. Короче, я его на Clipper написал. Потом еще раза 3 переделывал и вырос он в полную бухгалтерию. Если нужна помощь - ответь, я нарисую примерный список таблиц. Да, а суммовой учет тебе нужен, или хватит количественного ?


 
KSK   (2005-04-29 11:43) [28]

Сам вроди и писал учёт готовой продукци начиная с FoxPro  - и скажу не завидую кто сейчас пытается использовать локальные таблицы типа dbf или db. Сам мучался с создаванием кучи этих временных таблиц - время выполнения страшно и сказать..... эти индексы, связи, бизнес-правила... удалив в главной таблице запись - выполняй кучу запросов на удалении в подчинённых... Все через это проходят. А на счёт    
> ANB ©  
суммового учёта - за 10 лет так и не пришёл к единственному решению, в каждом случае по разному - по ситуации. Решений много - но оптимального, который бы мне понравился на все 100%, так и не нашёл.  И для

> >@k@DElpher  

почитай в каждой книге есть инсрукции по Interbase больше узнаешь о структуре баз данных, хранении и обработки информации. И на выбор много клиент-серверных субд. Interbase не плох - но мне больше по душе MS SQL Server. Удачи!!! Главное чтобы было желание и стимул!!! а всё остальное современем.


 
msguns ©   (2005-04-29 12:22) [29]

>KSK   (29.04.05 11:43) [28]
>Сам вроди и писал учёт готовой продукци начиная с FoxPro  - и скажу не завидую кто сейчас пытается использовать локальные таблицы типа dbf или db.

 Для однопользователького учета (а таких пользователей великое множество, ЧП например) юзать сервера-изврат чистейшей воды. Локалки-самое то. Дело не в дб, а в руках и голове.

>Сам мучался с создаванием кучи этих временных таблиц - время выполнения страшно и сказать..... эти индексы, связи, бизнес-правила... удалив в главной таблице запись - выполняй кучу запросов на удалении в подчинённых... Все через это проходят.

Неужели ? За 15 лет писано куча прог, исправно работающих до сих пор, в т.ч. и складского типа и не применял ни одной временной таблицы.
Для парадокса - да, есть грех - слет индексов. Для этого в каждой проге есть сервис с архивацией и восстановлением. Потери есть, но не существенные, пользователь привыкает довольно быстро самостоятельно забатиться о своей инфе. Я не говорю, что локалки - это хорошо. Я лишь утверждаю, что сваливать вину в уродливости программы на движок (BDE, например) - это "с больной головы на здоровую"

>суммового учёта - за 10 лет так и не пришёл к единственному решению, в каждом случае по разному - по ситуации. Решений много - но оптимального, который бы мне понравился на все 100%, так и не нашёл.  Успехов в поисках оптимальных решений.

Тут ничего не надо искать - суммовой учет надо делать всегда - еще никому он не мешал.

>но мне больше по душе MS SQL Server

Представляю частника, купившего такую прогу для учета своего товара. Первый же бросок по питанию и что он будет делать со скалой, отказывающейся поднять базу ?


 
ANB ©   (2005-04-29 12:42) [30]


> >но мне больше по душе MS SQL Server
- Oracle рулез !!! Не ломается. А вот для локалки не факт. Транзакций же нету. От отсутствия транзакций и все проблемы. Даже без констрэйнтов не так страшно. У клиппера тоже индексы слетали, у меня больше года без почистки базы серьезно работать не могли.

> суммовой учет надо делать всегда
- ну, во первых, хороший и настраиваемый не так просто, а во вторых, делал я клон своей бухгалтерии для своей части и выбросил суммовой учет (совсем был не нужен и там другие навороты были нужны), работать стало намного быстрее и надежнее. Правда у меня связка суммового с количественным учетом была на макросах построена.


 
msguns ©   (2005-04-29 13:11) [31]

>ANB ©   (29.04.05 12:42) [30]
>Правда у меня связка суммового с количественным учетом была на макросах построена.

Дааа, это неизлечимо ;(


 
Polevi ©   (2005-04-29 13:22) [32]

>msguns ©   (29.04.05 13:11) [31]
а в майкрософт то и не знают


 
ANB ©   (2005-04-29 13:59) [33]


> Дааа, это неизлечимо ;(
- а как бы это сделал ты, если формулы проводок нужно было дать возможность менять юзеру ? К тому же макросы я предварительно компилил.


 
KSK   (2005-04-29 14:04) [34]


> msguns ©   (29.04.05 12:22) [29]
>  Для однопользователького учета (а таких пользователей великое
> множество, ЧП например) юзать сервера-изврат чистейшей воды.
> Локалки-самое то. Дело не в дб, а в руках и голове.

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



> >msguns

> Первый же бросок по питанию и что он будет делать со скалой,
> отказывающейся поднять базу ?
тошо дбф-ники портятся и при потери сети - такого шо не бывает
???
> За 15 лет писано куча прог, исправно работающих до сих пор,
> в т.ч. и складского типа и не применял ни одной временной
> таблицы.
я понимаю - спользование временных таблиц идёт от плохого знания SQL, но написать нормальний запрос используя Query BDE я не знаю как можно??? посмотреть скоко возможностей появилось возможностей в SQL при использовании ADO - это привело к тому что я почти прекратил пользоваться временными таблицами. ПРоблема такого рода (тоже от не знания - я не возражаю) - есть к примеру одна главная таблица - с ней связываем больше двух таблиц подчиненных черех join, в которых надо сделать расчёты (sum() и другие) используя group by - вот если присутствует вот этот group by - связь происходит не верно. Посему делал по примерам с книги Кен Хендерсона - сначала сгонял всю в одну таблицу потом группировал, и работает быстро и никаких тебе  left join-ов, которые по всем книгам губительны для любой системы.


 
msguns ©   (2005-04-29 14:11) [35]

>Polevi ©   (29.04.05 13:22) [32]
>>msguns ©   (29.04.05 13:11) [31]
>а в майкрософт то и не знают

?

>KSK   (29.04.05 14:04) [34]
>вот если присутствует вот этот group by - связь происходит не верно.  

???
Запрос в студию


 
Polevi ©   (2005-04-29 14:13) [36]

>msguns ©   (29.04.05 14:11) [35]
а не знают они того что знает msguns, про то как падают базы..


 
Romkin ©   (2005-04-29 14:25) [37]

msguns ©   (29.04.05 12:22) [29]
>Для однопользователького учета (а таких пользователей великое множество, ЧП например) юзать сервера-изврат чистейшей воды. >Локалки-самое то. Дело не в дб, а в руках и голове.

Вот еще! Самое то? Назови мне хотя бы пару преимуществ BDE + dbf|db перед, например, Firebird Embedded? Никак не могу найти...
Я не говорю об Access и Foxpro, например, как полноценных средах, а именно о доступе из Delphi. Отвратно! Столько лишних телодвижений - все сам, проверки, целостность...
Кажется, последний раз я имел дело с локалкой в прошлом тысячелетии :)

Для парадокса - да, есть грех - слет индексов. Для этого в каждой проге есть сервис с архивацией и восстановлением. Потери есть, но не существенные, пользователь привыкает довольно быстро самостоятельно забатиться о своей инфе.
Несущественные потери? Ну-ну. Это ж, как правило, деньги. Такой склад, может, кладовщику и понравится... И что значит заботиться об инфе?! Если я ввел ее в БД, она там должна быть. Исключая стандартный форс-мажор вроде наводнения или пожара... А если записи исчезают - нафига такое надо?!
>Я не говорю, что локалки - это хорошо. Я лишь утверждаю, что сваливать вину в уродливости программы на движок (BDE, например) - это "с больной головы на здоровую"
Знаешь, хорошо писать на чем попало можно. Но зачем же мазохизмом заниматься?!


 
msguns ©   (2005-04-29 15:15) [38]

>Polevi ©   (29.04.05 14:13) [36]
>а не знают они того что знает msguns, про то как падают базы..

Ты хочешь сказать, что скала администится также просто, как, например, парадокс (Починить любую таблицу может даже ламер по инструкции из 4 строк или, на худой конец, просто разархивировать БД из сохраненного вчера архива) ?

>Romkin ©   (29.04.05 14:25) [37]
>Назови мне хотя бы пару преимуществ BDE + dbf|db перед, например, Firebird Embedded? Никак не могу найти...

Ясный ясень, что не найдешь. Особенно если искать и не собираешься. Преимуществ мало, но они есть. И главное из них - это то, что уже написано море работающих прог с использованием презираемых тобою локалок. Мне для того, чтобы "подкрутить" любую из них, надо от 5 мин до 5 дней. Ты что, предложишь мне все их переписать под FB ?

>Знаешь, хорошо писать на чем попало можно. Но зачем же мазохизмом заниматься?!

1. Вот это:
"Если я ввел ее в БД, она там должна быть"
или это
"А если записи исчезают - нафига такое надо?!"
и есть "что попало".

2. Что ты понимаешь под словом "мазохизм" ? Или есть необходимость пояснить тебе это слово ?

Зачем этот твой пост ? Чтобы показать, что ты основной, а мсганз - чайник ? Тем более, что мсганз чепухи-то не городил. Высказал свои взгляды, абсолютно, кстати, не безапелляционные (в отличие от твоих). А по-существу-то ? Про склад ?

Просто охота почесать гондурас ?


 
msguns ©   (2005-04-29 15:20) [39]

Вдогонку:
Вот на это:

1. Вот это:
"Если я ввел ее в БД, она там должна быть"
или это
"А если записи исчезают - нафига такое надо?!"
и есть "что попало".

2. Что ты понимаешь под словом "мазохизм" ? Или есть необходимость пояснить тебе это слово ?


прошу не обращать внимание. Отвлекали и не врубился в смысл фразы.


 
ANB ©   (2005-04-29 15:27) [40]


> msguns ©   (29.04.05 15:20) [39]
- не кипятись. Вообще то автор сабжа собирается писать новую прогу. Вот ему и советуют не начинать с локалок. Хотя MS SQK мне не нравится. Хотя бы потому, что 2000 не хочет на проф становиться, сервер ему подавай. Oracle не так привередлив, а возможностей больше. Правда и геморроя с администрированием тоже. В том, что переписывать готовую прогу только для перехода на SQL не выгодно - ты прав. Хотя многие таки потихоньку переписывают. И эти же многие продолжают использовать локалки хотя бы для хранения локальных данных, чтобы реестр не мусорить.


 
Sergey13 ©   (2005-04-29 15:31) [41]

2 [40] ANB ©   (29.04.05 15:27)
Ты серьезно рекомендуешь автору Оракл?


 
Polevi ©   (2005-04-29 15:34) [42]

>msguns ©   (29.04.05 15:15) [38]
>Починить любую таблицу может даже ламер по инструкции из 4 строк
там этого не требуется, "чинить таблицу" гыы :)
он железный, практически не требует к себе внимания - разумеется если база написана грамотно, ведь можно так прописать логику что будет все висеть изза блокировок - от кривых рук нет спасения

>ANB ©   (29.04.05 15:27) [40]
ох как мне это нравится "возможностей больше"
откуда такая уверенность ?


 
ANB ©   (2005-04-29 15:37) [43]

Я бы порекомендовал, но где он его возмет. А так :
- дока есть и одна из самых лучших + куча литератруы на русском, а мне раз по MS SQL книжка понадобилась - пол Москвы облазил - везде только использование, а программирование зачаточно.
- работает везде, даже на P3 c 256M и не очень тормозит
- можно начинать с простых вещей и медленно расти до использования сложных
- если изучит с применением на живом проекте, то будет крут.


 
ANB ©   (2005-04-29 15:39) [44]

+
- Многие вещи делаются в Oracle намного проще и синтаксически короче, чем в MS SQL
- Многое, что умеет Oracle, MS SQL просто не поддерживает синтаксически


 
Polevi ©   (2005-04-29 15:41) [45]

.. и устанавливать его нужно только на юникс, ибо виндовс сакс и маздай !
amen


 
Sergey13 ©   (2005-04-29 15:41) [46]

[43] ANB ©   (29.04.05 15:37)
>Я бы порекомендовал, но где он его возмет
я напомню.

[21] @k@DElpher   (28.04.05 13:17)
>Просто по идеи я в БД начинающий... И вообще самоучка. Потому что ещё школу не закончил
[26] @k@DElpher   (28.04.05 17:37)
>в 1С сам работаю(я её отцу в фирме запускаю)(почему я- потому, что жиё далеко и тут специалистов ВООбще нет!).

Ну-ну. 8-)


 
ANB ©   (2005-04-29 15:41) [47]


> ох как мне это нравится "возможностей больше"

попробуй на MS SQL написать запрос, вытягивающий дерево из таблицы :
Tbl (ID, Parent_ID, Name)


 
ANB ©   (2005-04-29 15:43) [48]


> >в 1С сам работаю(я её отцу в фирме запускаю)(почему я-
> потому, что жиё далеко и тут специалистов ВООбще нет!).
>
> Ну-ну. 8-)
- ты думаешь, ручками делать все в локальных базах проще, чем прочитав книжку по SQL, свалить все это на сервер ?


 
Sergey13 ©   (2005-04-29 15:43) [49]

И охота вам в пятницу перед пасхой такие споры затевать. 8-)


 
Polevi ©   (2005-04-29 15:43) [50]

зачем пробовать, как написал 3 года назад так и пользуюсь


 
msguns ©   (2005-04-29 15:44) [51]

>Polevi ©   (29.04.05 15:34) [42]
>он железный, практически не требует к себе внимания - разумеется если база написана грамотно, ведь можно так прописать логику что будет все висеть изза блокировок - от кривых рук нет спасения

Абсолютно справедливо. В том числе к "локалкам".

От склада плавно перешли к спору куликов о болотах. А мне вот не нравится скала тем, что там нет, например, генераторов. Нет полноты управления транзакциям с клиента. Нет UDF. Тяжела как беременная свинья, что в инстале, что в работе. Требования к системе непомерные и т.д.
И вообще, может хватит ?


 
Sergey13 ©   (2005-04-29 15:45) [52]

2[48] ANB ©   (29.04.05 15:43)
>прочитав книжку по SQL, свалить все это на сервер ?
Т.е. как только он прочитает туда сразу все само и упадет? Включая налогообложение? 8-)


 
ANB ©   (2005-04-29 15:46) [53]


> зачем пробовать, как написал 3 года назад так и пользуюсь
- а показать можешь ?


 
ANB ©   (2005-04-29 15:48) [54]


> Sergey13 ©   (29.04.05 15:45) [52]
- а на парадоксе ему налогообложение писать намного легче будет. Кстати, автор топика давно свалил. Может на женщин перейдем ?


 
KSK   (2005-04-29 15:55) [55]


> msguns ©

я всегда прислушывался к вашим и sniknik нравоученьям - за что всегда очень благодарен, но при своем мнении останусь - локальные системы проще и не требуют особого администрирования - но их тяжелей создавать - зато если постараться то они работаю даже надёжней чем клиент-серверные приложения. А работают они надёжней бо расчитаны на одного пользователя. Но ещё раз говорю - создавать систему для меня легче на базе MSSQLServer чем дбф. Кому на чём легче на том и работаем!!!



>
> >KSK   (29.04.05 14:04) [34]
> >вот если присутствует вот этот group by - связь происходит
> не верно.  
>
> ???
> Запрос в студию

шото типа такого - остаток на начало+выпуск+реализовано- остаток виходной. Запрос следующий:

select a.kod, sum(b.kolsh), sum(c.kol)
from prod a left join  wupprod b on a.kod=b.kod
left join realprod c on a.kod=c.kod
group by a.kod

делая group by только по одной таблице и сравниваю результат:

select с.kod,  sum(с.kol)
from realprod с
group by с.kod

результат не одинаков.  Где-то затупил - верю. Но где???


 
Polevi ©   (2005-04-29 15:55) [56]

CREATE FUNCTION TreeFromTable (@Root INT)  
RETURNS @T TABLE (ID INT, Owner INT, level INT) AS  
BEGIN
 DECLARE @level INT
 SET @Level=0
 INSERT @T SELECT @Root, 0, 0

 while exists(SELECT * FROM @T T, Structure S WHERE
T.level=@level and S.Owner=T.ID)
begin
 INSERT @T (ID,Owner,Level)
 SELECT S.ID, S.Owner, @level+1 from @T T, Structure S WHERE T.level=@level and S.Owner=T.ID
 SET @level=@level+1
end

RETURN
END


 
ANB ©   (2005-04-29 16:08) [57]


> Polevi ©   (29.04.05 15:55) [56]
- а просто запросиком ?
Oracle :


select     *
     from Tbl
start with ID = :Root_ID
connect by Parent_ID = prior ID

А если приор переставить, то развернет цепочку вверх. Можно и визуально дерево изобразить, если Level юзать. И запихать в подзапрос.


 
ANB ©   (2005-04-29 16:10) [58]

А пакеты в MS SQL есть ?
А как там вложенные циклы по курсору реализованы, просто жуть.
Постоянно объявлять курсоры, фетчить, заводить переменные.


 
ANB ©   (2005-04-29 16:16) [59]


> результат не одинаков.  Где-то затупил - верю. Но где???
проверь таблички wupprod и realprod на то, что все их коды есть в prod. А так - надо данные смотреть.


 
msguns ©   (2005-04-29 16:21) [60]

>KSK   (29.04.05 15:55) [55]
>но при своем мнении останусь - локальные системы проще и не требуют особого администрирования - но их тяжелей создавать - зато если постараться то они работаю даже надёжней чем клиент-серверные приложения. А работают они надёжней бо расчитаны на одного пользователя. Но ещё раз говорю - создавать систему для меня легче на базе MSSQLServer чем дбф. Кому на чём легче на том и работаем!!!

Самое интересное, что твое мнение совпадает с моим ;))

Наверное потому, что парадокс давно уж приказал долго жить (в смысле развития) и там даже близко нет таких удобных и мощных инструментов проектирования БД, как QA в MSSQL или IBExpert в IB/FB

>ANB ©   (29.04.05 16:10) [58]
>А как там вложенные циклы по курсору реализованы, просто жуть.
Постоянно объявлять курсоры, фетчить, заводить переменные.

Во-во. А еще сплошные временные таблицы.. После suspend`а в IB все это смотрится архаизмом каким-то


 
Polevi ©   (2005-04-29 16:21) [61]

>ANB ©   (29.04.05 16:08) [57]
у меня и так работает
>Постоянно объявлять курсоры, фетчить, заводить переменные
да, программрование это вообще отстой, постоянно надо чтото объявлять, переменные какието, циклы
кошмар


 
ANB ©   (2005-04-29 16:22) [62]


> Polevi ©   (29.04.05 15:55) [56]
- и еще подкожничек - что будет, если я попытаюсь создать табличку в MS SQL типа
T1 (
S1 varchar(4000),
S1 varchar(4000),
S1 varchar(4000)) и проинсертить с полным размером строки ?


 
Polevi ©   (2005-04-29 16:24) [63]

>msguns ©   (29.04.05 16:21) [60]
аналог suspend смотреть в [56]
и не надо песен про то как не используюся временные таблицы в oracle
это очень удобное средство манипулирования данными, и называть их архаизмом просто непрофессионально


 
Polevi ©   (2005-04-29 16:24) [64]

>ANB ©   (29.04.05 16:22) [62]
сообщение о размере страницы получишь, учитель


 
msguns ©   (2005-04-29 16:25) [65]

>Polevi ©   (29.04.05 16:21) [61]

А ведь уел тебя ANB, что ты в окопы-то полез ?
Уел пацан деда !


 
ANB ©   (2005-04-29 16:26) [66]


> да, программрование это вообще отстой,
- не, за это мне деньги платят. Но так же намного проще :

for CurVar in (select * from Tbl) loop
. . .
А здесь можно юзать CurVar.Field1 и прочее
end loop;

Никаких проблем с открытием/закрытием и прочим. Хотя можно и как обычно, но такие курсоры обычно передают или возвращают.


 
Polevi ©   (2005-04-29 16:28) [67]

и зря вы со мной спорите
у меня работает крупная распределенная система на ms sql 2000 с сотней одновременных подключений и милионами записей
а ваши академические наезды - собака лает караван идет

на oracle я такого не писал - и молчу в тряпочку про то чего не знаю
а у вас просто словесный понос какойто


 
Polevi ©   (2005-04-29 16:29) [68]

>msguns ©   (29.04.05 16:25) [65]
не хами


 
ANB ©   (2005-04-29 16:34) [69]


> крупная распределенная система на ms sql 2000
- тут снимаю шляпу. Обмен между серваками на MS SQL пока круче сделан. Хотя я еще 10G не видел. И бэкап MSSQL в десятки раз быстрее снимает и ставит, чем Oracle дампы. Правда, при восстановлении бэкапа можно умудриться и базу навернуть, но в Oracle вообще сначала надо схему пересоздать.


 
msguns ©   (2005-04-29 16:38) [70]

>Polevi ©   (29.04.05 16:29) [68]
>не хами

И в мыслях не было. Шутка, не более. С подкольным подтекстом. Если обидел, извиняюсь. Без проблем.
Никто не сомневается, что ты знаток скалы, но не одна она в мире БД.
Однако по сабжу-то что-то ничего от тебя не прозвучало.

На счет "работает". У меня работает несколько десятков многопользовательских систем на 3-30 пользователей. И не 3 года, а по 5, по 6, и даже по 10. Писано на парадоксе. Тем не менее я не пытаюсь всех убедить, что парадокс рулит, а все остальное - отстой.

По поводу suspend. Все глаза проглядел - не увидел аналога. Если не в лом и не обиделся на меня еще, то прокомментируй, пожалуйста, ибо я в скале почти новичок.


 
ANB ©   (2005-04-29 16:46) [71]


> ms sql 2000 с сотней одновременных подключений
- я работал на небольшой базе, в таблицах не больше 500 миллионов записей, а подключений не больше 3000 одновременно, но сделана она была на Oracle 8. Правда репликация была не автоматическая, а писана ручками, но связывала 10 филиалов (с 2-3 серверами в каждом) от Сибири до СПб по разнородным каналам, включая DialUp.


 
Romkin ©   (2005-04-29 17:01) [72]

msguns ©   (29.04.05 15:15) [38] Хм...
Не хами
>Romkin ©   (29.04.05 14:25) [37]
>Назови мне хотя бы пару преимуществ BDE + dbf|db перед, например, Firebird Embedded? Никак не могу найти...

>Ясный ясень, что не найдешь. Особенно если искать и не собираешься. Преимуществ мало, но они есть. И главное из них - это то, что уже написано море работающих прог с использованием презираемых тобою локалок.

Это преимущество?! На клиент-сервере тоже написано море работающих прог, и что? Какие преимущества все-таки? Я ведь тоже писал и на фоксе, и db пользовал. Не вижу я их, а у сервера - их море...
Связываться с ними просто не хочу. На клиент-сервере БД пишется раза в два быстрее, при желании. По крайней мере, у меня так. И это не считая монтирования в прогу презервативов для контроля и восстановления целостности...

>Мне для того, чтобы "подкрутить" любую из них, надо от 5 мин до 5 дней. Ты что, предложишь мне все их переписать под FB ?

Я это предлагаю? Работает - не трогай. А вот новое лучше уж писать на клиент-сервере, оно быстрее и надежнее.

>Зачем этот твой пост ? Чтобы показать, что ты основной, а мсганз - чайник ? Тем более, что мсганз чепухи-то не городил. Высказал свои взгляды, абсолютно, кстати, не безапелляционные (в отличие от твоих).

В чем отличие:
"Для однопользователького учета (а таких пользователей великое множество, ЧП например) юзать сервера-изврат чистейшей воды. Локалки-самое то. Дело не в дб, а в руках и голове."
от
"Отвратно! Столько лишних телодвижений - все сам, проверки, целостность..."
???
По-моему, стиль я сохранил :)) И не понимаю я, чем лучше для одного пользователя связка BDE+dbf чем FB embedded?! И почему второе - изврат?!

>А по-существу-то ? Про склад ?
А по существу - все уже сказали. Мое мнение - неверно выбранный инструментарий плюс ошибочная структура БД. Что тут сказать? Учите матчасть, как производится движение товара, как проектировать БД и тд... Это уже сказали.

И не хами


 
Polevi ©   (2005-04-29 17:01) [73]

>ANB ©   (29.04.05 16:46) [71]
работал с ораклом - ну и советуй по нему
только не надо тут холи вор если не знаешь того против чего агитируешь

>msguns ©   (29.04.05 16:38) [70]
насколько я понимаю suspend помещает запись в список тех которые будут возвращены процедурой
в моем примере это делает insert @t


 
Fay ©   (2005-04-29 20:00) [74]

ANB ©   (29.04.05 16:08) [57]
Попробуй сделать на Oracle это

declare @v int
update Table1 set
 Num = Num + 1,
 @Num = Num + 1
where ID = 1


или это :
declare
 @v varchar(4000)

select
 @v = ""

select
 @v = @v + Field1
from Table1


Ещё можешь попытаться всунуть в ХП запрос со вложенностью подзапросов > 4. На досуге.


 
Fay ©   (2005-04-29 20:01) [75]

Имелось ввиду
declare @Num int
update Table1 set
Num = Num + 1,
@Num = Num + 1
where ID = 1


8)


 
@k@DElpher   (2005-04-30 11:13) [76]

1) Автор ни куда не свалил:) Просто, когда сюда ходил- ничего не было:)...
2)В общем я понял, что не понял, поняли ли вы, что мне нужно.
3)Мне нужен простой учёт склада, который надо будет запускать на странинном компе(вроде бы даже не на двойке), и сетки там не будет и к этому компьютеру я буду подходить довольно редко=> как я понял из выше изложенного- в моём случае ни о каких КЛИЕНТ-СЕРВЕР, думать не надо:)
4)Есть в мире, что почитать(проверенного)  о написании складских программ(простых, и не простых:)  и о СУБД для этого? Можно в электронном, можно в бумажном виде? Посоветуйте что-нибудь.
А эту программку всё-таки напишу в парадоксе(хотя бы для собственного развития)...


 
@k@DElpher   (2005-04-30 11:15) [77]

Да и ещё:
не будет у меня там налогов, мощной кассы, и всяких прочих документов- только приход, реализация, остатки ТМЦ...


 
@k@DElpher   (2005-04-30 11:21) [78]

и совсем забыл! Снаступающей Пасхой!


 
ANB ©   (2005-05-03 09:43) [79]


> Fay ©   (29.04.05 20:01) [75]

1) declare @Num int
update Table1 set
Num = Num + 1,
@Num = Num + 1
where ID = 1 - это для чего (ТЗ, если можно)?
2) declare
@v varchar(4000)
select
@v = ""
select
@v = @v + Field1
from Table1

в Oracle так :
declare
v varchar2(4000);
begin
v := "";
select v || min(Field1) into v from Table1 where ID = 1;
end;

Да, Oracle клинит на векторных запросах, нельзя юзать from в update. Но это легко разруливается через rownum, rowid и курсоры. Тем более, что работать с ними намного проще, чем в MS SQL.


 
ANB ©   (2005-05-03 09:48) [80]


> странинном компе(вроде бы даже не на двойке),
на 286 ???????


 
@k@DElpher   (2005-05-03 12:59) [81]

примерно:) Но Windows встанет...:)


 
ANB ©   (2005-05-03 13:34) [82]

На 286 Win32 не встанет. Он 16 разрядный. Минимум 386, но надо напихать 8 Мб RAM и будет жутко тормозить. Для такихь компов надо под DOS писать. Delphi умрет (и подойдет только 1.0)


 
Fay ©   (2005-05-03 13:55) [83]

ANB ©   (03.05.05 9:43) [79]
Я полагал, что Вы разбираетесь в том, что сравниваете.
(1) - выборка и изменение значения одновременно;
(2) - это конкатенация значений поля из всех записей.
>> в Oracle так :
Не так. Это только для одной строки. Да и ценность v := "" не совсем очевидна.

С rownum в Oracle действительно легче работать - в MSSQL его просто нет, как нет top в Oracle. Rowid подойдёт только при serializable.
Курсоры for ... in (...) loop удобнее, спору нет.
Но работать с сервером, у которого такая дебильная диагностика ошибок - спасибо, только если Родина скажет "надо".


 
ANB ©   (2005-05-03 15:56) [84]


> Но работать с сервером, у которого такая дебильная диагностика
> ошибок - спасибо, только если Родина скажет "надо".
- это про MS SQL ? Вот уж где дебильная диагностика . . .
Обработки исключений фактически нет, понятия валидности нет.
Пакетов нет.
А зачем Oracle top, если есть rownum ? К тому же rownum умеет больше.
MS SQL круче следующими вещами :
- векторные запросы (into в несколько полей, в Oracle так тоже можно, но гарантированно нарвешься на ошибку выполнения)
- from в update и delete
- операции с набором значений как у тебя в 2 (даже не знал :((()
иногда это удобно, а то в Oracle для подобных вещей надо хранимку заводить, хотя можно обойтись и безымяным блоком.
- отсутствие mutating в триггерах, но ради этого в триггера приезжают не строки, а наборы данных и частенько это криво обрабатывают, даже в примерах из книжек.
Большой глобальный минус - без компа с NT Server ты его не поднимешь. От чего я с него окончательно и слез.


 
Fay ©   (2005-05-03 16:19) [85]

2 ANB ©   (03.05.05 15:56) [84]
> без компа с NT Server
Это не совсем правда 8)
> триггера приезжают не строки, а наборы данных
В ora тоже (тоже так можно)

О диагностике - я имел ввиду ситуцию, когда при компилляции (или выполнении) выдаётся сообщение об ошибке, совершенно не соотв. действительности.

Про исключения - это да. Есть такая беда.

>> Пакетов нет
Дождёмся MSSQL 2005.

В MSSQL хинты намного удобнее, и можешь быть уверен - сервер сделает именно то, что ты напишешь.

Ладно. Кончаем холивор. Я работаю и с MSSQL 2000, и с Oracle 9.2, и под каждым не хватает чего-либо.


 
@k@DElpher   (2005-05-03 18:38) [86]

Ну значит 386... Во всяком случае на нём с небольшими тормозами 1С(торговля+склад) И АвтоКаталог, который на FB пашет...
Если и будет что-то слетать, то другой купят:)


 
ANB ©   (2005-05-04 09:31) [87]


> В ora тоже (тоже так можно)
- нельзя. В оракл только строки приезжают. New и Old.
Гы, у меня такой же набор.
и под каждым не хватает чего-либо - на этом и закруглим. Полностью присоединяюсь. В принципе спор то был о выборе настольной СУБД. Я почему оракл рекомендовал - возможности крутые и станет на любой комп. А MS SQL сервер потребует (вот козлы, неплохая настольная база была, и админить ее просто).

> @k@DElpher   (03.05.05 18:38) [86]
- если 1С стоит, то и оракл встанет, если места хватит и найдешь


 
ANB ©   (2005-05-04 09:32) [88]


> @k@DElpher   (03.05.05 18:38) [86]
- тебе примерный набор таблиц посоветовать ?


 
Sergey13 ©   (2005-05-04 09:40) [89]

2[87] ANB ©   (04.05.05 09:31)
>  Я почему оракл рекомендовал - возможности крутые и станет на любой комп.
Все таки странное преимущество. Мало ли что встанет на комп. Все таки Оракл не самая простая СУБД, при всей моей любви к нему. Я осваивал его самостоятельно - жуткая вещь. Особенно сразу после "настольных" БД типа Парадокс.
ИМХО, для автора FB - самое оно.


 
ANB ©   (2005-05-04 10:01) [90]


> жуткая вещь
- не такая уж и жуткая. Я пред началом работы изучал его неделю. И потом сразу в бой. Я к тому, что если он сразу на нем писать начнет, то потом сможет круто на работу устроится. А FB такого преимущества не даст. Книг я по нему в магазинах не видел. С MS SQL зарплата по любому меньше (сам проверял).


 
Sergey13 ©   (2005-05-04 10:07) [91]

2 [90] ANB ©   (04.05.05 10:01)
> Я к тому, что если он сразу на нем писать начнет, то потом сможет круто на работу устроится.
Или бросит все это к чертовой матери. 8-)

ЗЫ: А если еще и лицензиями озаботиться........


 
Polevi ©   (2005-05-04 10:18) [92]

а оракл что бесплатный ?


 
Danilka ©   (2005-05-04 10:21) [93]

[92] Polevi ©   (04.05.05 10:18)
Для разработчика, таки, бесплатный. Для пользователей - нет. Впрочем, есть и персонал версии.


 
Sergey13 ©   (2005-05-04 10:25) [94]

2[93] Danilka ©   (04.05.05 10:21)
> Впрочем, есть и персонал версии.
Которые тоже денег стОят, между прочим. 8-)


 
ANB ©   (2005-05-04 10:37) [95]


> Которые тоже денег стОят, между прочим. 8-)
- ты сам когда себе последний раз лицензионный софт покупал ? Кто у него в магазине будет это проверять ? Проблема с закачкой, т.к. весит инсталляшка 9.2 не меньше гектара и по почте высылать - для меня нагло, да и получать он будет долго.


 
Sergey13 ©   (2005-05-04 10:43) [96]

2[95] ANB ©   (04.05.05 10:37)
>- ты сам когда себе последний раз лицензионный софт покупал ?
Я сам не покупаю - у меня лично и компа то нет. 8-) А на работе, ты не поверишь, все лицензионное.
Нравится тебе Оракл в ларьки ставить - ставь. Мне по барабану. Свои сомнения в целесообразности этого я уже высказал.


 
Danilka ©   (2005-05-04 10:44) [97]

[94] Sergey13 ©   (04.05.05 10:25)
Хм, значит я отстал от жизни. Вроде видел какую-то сильно урезаную бесплатную версию.

[95] ANB ©   (04.05.05 10:37)
Ну-ну. Тут у нашей конторы одни заказчики есть, еле-еле их уговорили, один из сильнейших доводов против - ПО под Орокол, а заказчики для других целей купили МС-Скуль, теперь еще и Орокол покупать, это значит удваивать стоимость покупки нашего ПО (по их словам).


 
Sergey13 ©   (2005-05-04 10:49) [98]

2 [97] Danilka ©   (04.05.05 10:44)
>Хм, значит я отстал от жизни. Вроде видел какую-то сильно урезаную бесплатную версию.

Так для разработки и изучения бесплатно все вроде. Хоть ентерпрайз ставь. Как только БД начинает эксплуатироваться - плати. По прайсу который есть у меня (старенький правда, 1.5 года) Персонал - 400$ Лайт - 100$.


 
Danilka ©   (2005-05-04 10:57) [99]

[98] Sergey13 ©   (04.05.05 10:49)
Понятно. Ну, значит я ошибся. Может, про Лайт думал, что бесплатный - сам этим интересовался давно, может год назад. Только, кажись, этот Лайт настолько урезан, что бесплатные альтернативы ему фору 100 очков дадут. Пора-бы и Ороклу что-нибудь бесплатненькое выкинуть, в свете таких альтернатив. :)

ps. если весь оффтопик из ветки вырезать, останется от нее хотя-бы треть? :))


 
Danilka ©   (2005-05-04 12:55) [100]

[84] ANB ©   (03.05.05 15:56)
> Большой глобальный минус - без компа с NT Server ты его
> не поднимешь. От чего я с него окончательно и слез.

Просто интересно, а разве Орокол встанет на Вин98?

А так, по теме холивора, в МС-Скуле меня просто убивает отсутствие нормальной работы триггеров instead of на вьюхах. :(((

Пример:
create table t_test (
 y1 int identity,
 y2 varchar(10),
 primary key (y1))
go
create view v_test as
select y.y1, y.y2 from t_test y
go
create trigger tr_test on v_test instead of insert as
print "bla-bla-bla"
go

при этом запрос: insert into v_test (y2) values ("test") проходит с ошибкой "поле y1 не нулл"... почему??? :(((
запрос insert into t_test (y2) values ("test") конечно идет на-ура.
и запрос  insert into v_test (y1,y2) values (1,"test") тоже идет на ура - рисует такое красивое "бла-бла-бла", а в таблицу ниче не инсертит, автоинкремент не инкрементицца.
ну нафига проверки ДО триггера заменяющего стандартный инсерт??? мало-ли куда реально я распихаю данные которые мне пришли?


 
evvcom ©   (2005-05-04 14:44) [101]


> KSK   (29.04.05 15:55) [55]
>
> select a.kod, sum(b.kolsh), sum(c.kol)
> from prod a left join  wupprod b on a.kod=b.kod
> left join realprod c on a.kod=c.kod
> group by a.kod
>
> делая group by только по одной таблице и сравниваю результат:
>
> select с.kod,  sum(с.kol)
> from realprod с
> group by с.kod
>
> результат не одинаков.  Где-то затупил - верю. Но где???

Естественно не одинаков. Дело в том, что в таблицах a, b и с связь по kod не один к одному. Например,

b.kod b.kolsh | c.kod с.kol
1     1       | 1     3
1     2       | 1     4

Ты ожидал увидеть в результате
1 3 7

На самом деле после join-ов получишь такое
kod kolsh kol
1   1     3
1   1     4
1   2     3
1   2     4

А уже только потом суммирование приведет к результату
1 6 14

Вот в этом и грабли.


 
Fay ©   (2005-05-04 15:28) [102]

Danilka ©   (04.05.05 12:55) [100]
Согласен. Ч/з ...опу.
Сделай
create view v_test as
select y1 = y.y1 + 0, y.y2 from t_test y
go

8)


 
@k@DElpher   (2005-05-04 19:06) [103]


> > @k@DElpher   (03.05.05 18:38) [86]
> - тебе примерный набор таблиц посоветовать ?

Посоветуй:) Но на оракле я пока делать не буду...(Мои таблицы готовы, только программно всё устроить 8-) )


 
ANB ©   (2005-05-05 13:28) [104]


> @k@DElpher   (04.05.05 19:06) [103]

Ну, примерно, не претендуя на крутость :
- Список клиентов (отправителей, получателей), включая сам склад и частных лиц
- Список документов (обязательно включить отправителя и получателя)
- Справочник товаров
- Проводки, привязанные к документу (как строки документа). Я бы включил дублем тоже отправителя и получателя, потом легче отчеты делать, но можно и оставить нормализованным, то есть доставать их потом из документа.
- Остатки по каждому клиенту и товару

При добавлении / изменении проводок одновременно корректируй текущий остаток по товару. Тогда в любой момент ты сможешь получить текущий остаток и рассчитать остатки на любой момент времени. Это намного быстрее, чем доставать остатки от начала времен, хотя и сложнее писать.


 
Polevi ©   (2005-05-05 13:46) [105]

гм остатки по клиенту это как


 
Sergey13 ©   (2005-05-05 13:53) [106]

2[104] ANB ©   (05.05.05 13:28)
таблица под остатки вообще не нужна. В зависимости от вида учета их можно хранить или в товарах или в документах.


 
Danilka ©   (2005-05-05 21:32) [107]

[102] Fay ©   (04.05.05 15:28)
Хм, работает! Спасибо. :)


 
msguns ©   (2005-05-06 09:21) [108]

>ANB ©   (05.05.05 13:28) [104]

Насчет проводок - это ты загнул ;) Если их добавлять в БД, то надо еще как минимум пару справочников (план счетов, корреспонденции+типовые проводки) + схему их экспорта на Баланс (Гл.Книга) или бух.программу.

Где платежи ? Где прайсы ? Как в "списке документов" держать счета, заявки и заказы, не говоря уж о накладных возвратов ? Что делать с внутренним перемещением ? Розницы типа нету ?
Как быть с инвентаризацией, пересортицей и списанием ?


 
ANB ©   (2005-05-06 12:45) [109]


> msguns ©   (06.05.05 09:21) [108]
- автор топика просил ПРОСТОЙ склад. Для розницы. Зачем там счета и заказы ? Потом можно добавить. А проводки не суммовые, а количественные - типа : отправитель, получатель, код товара, количество, документ.
Кстати, на этой простой схеме можно довольно сложный учет построить. У меня было тоже самое + суммовой учет и у меня ни разу не было проблем, что я не смог выполнить требования заказчика. Хотя ставил и частникам и средним торговым конторам, типа военторга.
А вот хранение остатков в проводках уже проходили. Потом, чтобы их получить, запрос по 30 минут выполняется.


 
msguns ©   (2005-05-06 13:01) [110]

>ANB ©   (06.05.05 12:45) [109]
>А проводки не суммовые

Мы, видимо, разный смысл вкладываем в это слово. Я имею в виду проводку бухгалтерскую, а ты ?
Если просто документ проведен или нет, то для этого хватает статуса документа (int или char(1)): не введен, введен (суммы совпадают с контрольными), проведен, откачен.
Все ИМХО, ессно ;)


 
ANB ©   (2005-05-06 13:06) [111]


> Я имею в виду проводку бухгалтерскую, а ты ?
- нет конечно. Я проводками называю все движение того, что учитывается. Привычка :))). Проще строки документа одновременно считать проводками.
Бухгалтерские, я так понял, не очень нужны.
А отложенное проведение . . . Как сказать. Я делал 2 варианта. Снятие остатка сразу и блокировка, а потом проводка. У обоих есть достоинства и минусы.


 
wHammer ©   (2005-05-06 13:36) [112]

Мне например также все в 99-м (когда начинал) пели что Interbase это супер, ведь это клиент-сервер, а DBF и Paradox - файл-сервер а потому отстой полный. После написания пару приложений под Interbase (правда с небольшим количеством таблиц), придя на новую работу познакомился с человеком, который на Paradox"е мог сделать и делал всё. Знал его возможности от и до. Ну и меня завербовал. Теперь всегда использую именно Paradox. ИМХО к плюсам можно отнести бесплатность и простоту. За исключением "продвинутых" транзакций никаких важных приемуществ у клиент-сервера за все время не нашел. Зато знаю полно "тупых" кодеров, извените, которые гнут пальцы налево и направо про Interbase и про SQL, хотя сами ничего кроме справочных приложений типа техпроцессов не написали, а про какой-либо учет вообще ничего не слышали. Ни одной временной таблицы у себя я также не создал. Так что я msguns"а поддерживаю полностью.


 
Danilka ©   (2005-05-06 13:59) [113]

[112] wHammer ©   (06.05.05 13:36)
Ну-ну. Самое простейше - пришел я с флешкой, забрал все твои парадоксовские файлы и все. Делаю с ними что угодно.
А если клиент-сервер, то не имея физ.доступа к серверу, при правильно написаной системе, ты никогда не сможешь украсть базу.

И это не единственная проблема, их есть куча, просто влом рассказывать очевидные вещи.


 
wHammer ©   (2005-05-06 14:18) [114]


> Danilka ©   (06.05.05 13:59) [113]


Если человек имееет базу но не имеет прав доступа к информации в базе через приложения клиента то поправить что-либо в ней физически будет довольно сложно, т.к. например документ, хранит информацию, например сумму накладной, не только в таблице документа, но и во всех связанных с этим документам таблицам по которым он делает "проводки", поэтому разобраться во всем и изменить сумму везде будет довольно сложно.

А что касается краж, то это отдельная тема, украсть, при желании можно все, например сам сервер. Однако, насколько я знаю, никая БД не может обладать юридической силой. Т.е. она не может быть доказательством в суде, например при нарушениях в уплате налогов. Большого смысла ее красть я не вижу. Хотя возможно я и ошибаюсь.


 
ANB ©   (2005-05-06 14:24) [115]


> Большого смысла ее красть я не вижу
- ну во первых воруют базы для использования информации в ней. Хотя ты прав. Локальную базу при желании можно защитить, а унести базу можно и с сервера. Просто многие вещи на SQL + хранимки и триггера делаются намного легче, чем при локальных таблицах. Кстати, я видел и смешанные подходы.


 
Danilka ©   (2005-05-06 14:30) [116]

[114] wHammer ©   (06.05.05 14:18)
Крадут не для того, чтобы в  суде что-то доказывать, а, например, для того, чтобы продавать компашки: "паспортные данные всех россиян, свежайшая база 2005 года", да и еще причин дофига, тот-же список поставщиков наработаный годами.
И украсть сервер намного сложнее и заметнее, чем уговорить знакомую тетку операционистку вставить флешку и все скачать. И разобраться потом с любой базой, хоть Орокловой, имея соответствующие физические файлы - это лишь вопрос времени.
А в клиент-сервере можно, например, все сделать через вьюхи, которые фильтруют по юзеру таблицы и дают ему доступ только к тем записям таблиц, куда ему можно. А на сами таблицы вообще ни у кого доступа нет. Тригера, логи, при правильной организации можно очень сильно сузить круг подозреваемых в утечке информации.

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


 
ANB ©   (2005-05-06 14:38) [117]


> с любой базой, хоть Орокловой
- хе, ну дам я тебе dbf от таблспейсов ораклы, чего ты с ними делать то будешь ?
И что, Oracle - не клиент/сервер ?


 
wHammer ©   (2005-05-06 14:44) [118]

ANB ©   (06.05.05 14:24) [115]
Danilka ©   (06.05.05 14:30) [116]


Да я ведь не оспариваю, я ведь специально подчеркнул в [112] слово "важных". Извените, но настолько важных проектов как например "база стратегических запасов природных ресурсов России" я конечно не делал. Делал учетные задачи, склады, планирование и расчет зарплаты/налогов, а кому такие данные красть понадобиться? Кто и кому их сможет продать?


 
Danilka ©   (2005-05-06 14:45) [119]

[117] ANB ©   (06.05.05 14:38)
Клиент-сервер. Это я написал к тому - что имея доступ к файлам БД, можно ее вскрыть всегда. Про Орокол были обсуждения и методики на sql.ru года полтора назад, когда я туда часто заглядывал.
Не хекс-редактором, конечно-же, приносишь на другой сервер и там шаманишь, как именно - не интересовался, просто отметил, что можно. Если тебе надо - ищи.


 
Danilka ©   (2005-05-06 14:46) [120]

[118] wHammer ©   (06.05.05 14:44)
Ну, вот есть у меня, например, знакомые, которые как-раз очень пекутся, чтобы база поставшиков никуда не ушла.


 
ANB ©   (2005-05-06 14:48) [121]


> расчет зарплаты/налогов, а кому такие данные красть понадобиться
- помнится слушок ходил на моей старой работе, что одному прогу кое что открутили напрочь, за то, что вынес с работы всего одну таличку - список клиентов. И продать, кажись, успел.
Зарплата в Москве - вообще вещь секретная.
Я тоже много писал для локалок и сейчас забыл это все как страшный сон.


 
Sergey13 ©   (2005-05-06 15:02) [122]

[112] wHammer ©   (06.05.05 13:36)
>За исключением "продвинутых" транзакций никаких важных приемуществ у клиент-сервера за все время не нашел.
Ну хоть что-то хорошее. 8-)

2[114] wHammer ©   (06.05.05 14:18)
>т.к. например документ, хранит информацию, например сумму накладной, не только в таблице документа, но и во всех связанных с этим документам таблицам по которым он делает "проводки", поэтому разобраться во всем и изменить сумму везде будет довольно сложно.

Всем. Включая автора проги. А уж найти причину расхождений (а они я уверен бывают, и не редко) вообще невозможно. 8-)

2[117] ANB ©   (06.05.05 14:38)
> - хе, ну дам я тебе dbf от таблспейсов ораклы, чего ты с ними делать то будешь ?
А если не только их, но все "соответствующие физические файлы"?


 
Fay ©   (2005-05-06 16:25) [123]

Sergey13 ©   (06.05.05 15:02) [122]
физические

ANB ©   (06.05.05 14:48) [121]
физические

Не стоит спорить. Такие героические люди (wHammer и др.) работая сами, создают рабочие места и для других программистов. Надо ценить это 8)


 
ANB ©   (2005-05-06 16:33) [124]


> А если не только их, но все "соответствующие физические
> файлы"?
- даже если я тебе всю папку скопирую, не факт, что ты быстро разберешся, как это все поднять. Oracle хитрая штука. Я, например, не знаю как это сделать. Мне проще дамп снять. Хотя наши админы грят, что умеют, но это геморрно.
В принципе, можно и локальные файлы так закрыть, что даже если вынесешь - не скоро в них разберешся.


 
@k@DElpher   (2005-05-08 14:02) [125]


> Ну, примерно, не претендуя на крутость :
> - Список клиентов (отправителей, получателей), включая сам
> склад и частных лиц
> - Список документов (обязательно включить отправителя и
> получателя)
> - Справочник товаров
> - Проводки, привязанные к документу (как строки документа).
> Я бы включил дублем тоже отправителя и получателя, потом
> легче отчеты делать, но можно и оставить нормализованным,
> то есть доставать их потом из документа.
> - Остатки по каждому клиенту и товару

Ну в общем я сам придумал ТОЧНО такую же схему:)...+ цены, ед.Изм...
Разве что, я не делал ОСТАТКИ... Потому что в этом можо смотреть только общие... А одна из самых главных фишек это остатки з периоды:)! о всё же сделаю... может быть... Чтоб всегда оперативно посмотреть можно было:)
 А такие проводки вроде бы называются ДВИЖЕНИЕМ(товара)



Страницы: 1 2 3 4 вся ветка

Форум: "Базы";
Текущий архив: 2005.06.14;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.86 MB
Время: 0.045 c
3-1115573104
anton_m
2005-05-08 21:25
2005.06.14
вопрос по SQL


1-1117376417
aha
2005-05-29 18:20
2005.06.14
Как красиво как в Ворде например сделать функцию переименования


1-1117185097
electric
2005-05-27 13:11
2005.06.14
Прокрутка в TWebBrowser


1-1117179617
Svit_men
2005-05-27 11:40
2005.06.14
Как подменить нажатую клавишу


14-1116589520
Piter
2005-05-20 15:45
2005.06.14
Глюк со SmartFTP





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский