Столбцы-массивы в Interbase

← →
RDA © (2003-04-16 08:51) [0]

Если кто-либо использовал данные столбцы, поделитесь впечатлениями. Работать с ними можно напрямую или как-либо иначе. Используемые компоненты доступа FIBPlus. По определению вычитанному в книге, мне кажется в таких столбцах очень удобно хранить к примеру лицевой счет сотрудника.

← →
Alexandr © (2003-04-16 09:13) [1]

работать с ними можно. Но функциональность очень ограничена.
Я не видел никакой потребности в использовании массивов в реляционной БД, отчего была бы хоть какая нибудь польза.

← →
Johnmen © (2003-04-16 09:14) [2]

Делюсь.
Если не хочешь гиморроя - не используй.
Нет объективных причин их использовать.

← →
Fiend © (2003-04-16 09:51) [3]

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

← →
RDA © (2003-04-16 10:26) [4]

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

← →
Alexandr © (2003-04-16 10:29) [5]

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

← →
RDA © (2003-04-16 10:37) [6]

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

← →
Fiend © (2003-04-16 10:49) [7]

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

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

← →
RDA © (2003-04-16 11:13) [8]

>Friend
Не вижу разницы где делаются расчеты на клиенте или на сервере, вопрос об организации хранения информации за 12 месяцев. Частично для начислений и удержаний можно использовать и сервер, но часть начислений (по каждому человеку - 1,2 раза в год) бухгалтер должен считать сам.

← →
Соловьев © (2003-04-16 11:18) [9]

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

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

← →
Fiend © (2003-04-16 11:21) [10]

То RDA:

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

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

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

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

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

>>Соловьев
Это я понимаю, и частично буду делать расчеты на сервере.

Разница есть и очень большая.
Для выборок в различные отчеты (а зарплата и делается в основном для них) требуется "шариться" по нескольким таблицам, связанным иногда косвенно. Если все это делать на клиенте, придется создавать кучу временных таблиц и тащить их на клиент, там же и обновлять. ХП делает это заметно эффективнее.
Кроме того, данные о начислении зависят еще и от таких напрямую не связанных с з/пл сущностей БД, как табель, структура подразделений с окладами и должностями, плановый фонд, график работы (календарь предприятия) и т.д. Если при расчете все это
по очереди извлекается с сервера и тащится на клиент, а том потом "переваривается", то эффективность этого процесса весьма низкая. По сравнению с логикой на сервере. Я уж не говорю о том, что при изменении любого алгоритма (а они меняются не реже, чем соотв.законодательства) придется лопатить все проги.

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

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

>>MsGuns
Если изменить вопрос так:
Как правильней организовать хранение информации о начисления и удержаниях по сотруднику за 12 месяцев отчетного периода.

>RDA © (16.04.03 11:50)

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

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

Столбцы-массивы в Interbase Найти похожие ветки