Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Столбцы-массивы в Interbase [D5, IB6.x]

RDA © (2003-04-16 08:51:00)
Если кто-либо использовал данные столбцы, поделитесь впечатлениями. Работать с ними можно напрямую или как-либо иначе. Используемые компоненты доступа FIBPlus. По определению вычитанному в книге, мне кажется в таких столбцах очень удобно хранить к примеру лицевой счет сотрудника.

MsGuns (2003-04-16 12:59:00) [1]
>RDA © (16.04.03 11:50)

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

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

RDA (2003-04-16 11:50:00) [2]
>>MsGuns
Если изменить вопрос так:
Как правильней организовать хранение информации о начисления и удержаниях по сотруднику за 12 месяцев отчетного периода.

MsGuns (2003-04-16 11:38:00) [3]
Разница есть и очень большая.
Для выборок в различные отчеты (а зарплата и делается в основном для них) требуется "шариться" по нескольким таблицам, связанным иногда косвенно. Если все это делать на клиенте, придется создавать кучу временных таблиц и тащить их на клиент, там же и обновлять. ХП делает это заметно эффективнее.
Кроме того, данные о начислении зависят еще и от таких напрямую не связанных с з/пл сущностей БД, как табель, структура подразделений с окладами и должностями, плановый фонд, график работы (календарь предприятия) и т.д. Если при расчете все это
по очереди извлекается с сервера и тащится на клиент, а том потом "переваривается", то эффективность этого процесса весьма низкая. По сравнению с логикой на сервере. Я уж не говорю о том, что при изменении любого алгоритма (а они меняются не реже, чем соотв.законодательства) придется лопатить все проги.

Малый пример: расчет квартальной (полугодовой) премии.
Для "клиентского" варианта придется неминуемо делать несколько выборок довольно большого числа записей лицевых, фонда времени и прочего. Только для того, чтоб потом в проге по нескольким таким НД вычислить по каждому челу только одну сумму. (Вариант "все в одном запросе" катит далеко не всегда).
Для "серверного" варианта пишется одна-две ХП, всю кухню выполняющие внутрях и возвращающие уже готовые данные для добавления в лицевые (которые, кстати, могут быть сделаны и в самих ХП)

Похожая схема при расчете отпускных или больничных. Только кол-во народа меньше, а схема та же.

Fiend (2003-04-16 11:21:00) [4]
То RDA:

> Не вижу разницы где делаются расчеты на клиенте или на сервере

Жаль что невидишь. Очень жаль. Мне тогда просто не имеет смысла тебе что то подсказывать.

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

Или сильно трудолюбивый бухалтер, или просто софт невсеобъемлющий.

Что тут еще добавить?

RDA (2003-04-16 11:21:00) [5]
>>Соловьев
Это я понимаю, и частично буду делать расчеты на сервере.

Соловьев (2003-04-16 11:18:00) [6]

> Не вижу разницы где делаются расчеты на клиенте или на сервере

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

RDA (2003-04-16 11:13:00) [7]
>Friend
Не вижу разницы где делаются расчеты на клиенте или на сервере, вопрос об организации хранения информации за 12 месяцев. Частично для начислений и удержаний можно использовать и сервер, но часть начислений (по каждому человеку - 1,2 раза в год) бухгалтер должен считать сам.

Fiend (2003-04-16 10:49:00) [8]
Очень неправильно конечно шо всё на клиенте, но раз так то конечно чтобы уменьшить размер рекордсета затягиваемого на клиента луччехранить данные в одной строке обо всём. Но массив для этого не лучший способ. лучше отдельные поля.

Но всё таки лучше делать всё на сервере.
И вообще конечно трудно что то советовать когда делается через известное место.

RDA (2003-04-16 10:37:00) [9]
Программа - Зарплата.
У сотрудника есть лицевой счет (за каждый месяц - норма дней, отработано дней, начисления (около 10 видов), удержания (около 6 видов), сумма начислений, сумма удержаний, сумма на руки. И так за 12 месяцев.
Как лучше организовать хранение такой информации в базе данных если большинство расчетов виполняется на клиенте.

Alexandr (2003-04-16 10:29:00) [10]
есть масса способов.
Напиши задачу конкретнее. Что для чего.

RDA (2003-04-16 10:26:00) [11]
Вообщем вопрос пожалуй сводится к слудующему - никак не могу определиться как хранить лицевые счета сотрудников, если кто делал уже такое растолкуйте.

Fiend (2003-04-16 09:51:00) [12]
Объективные причины есть, когда заливаешь для перекройки БД разработанную много лет назад. Ранее это очень часто использовалось. А потом конечно лучше от них избавиться.

Johnmen (2003-04-16 09:14:00) [13]
Делюсь.
Если не хочешь гиморроя - не используй.
Нет объективных причин их использовать.

Alexandr (2003-04-16 09:13:00) [14]
работать с ними можно. Но функциональность очень ограничена.
Я не видел никакой потребности в использовании массивов в реляционной БД, отчего была бы хоть какая нибудь польза.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »