Форум: "Базы";
Текущий архив: 2003.05.05;
Скачать: [xml.tar.bz2];
ВнизСтолбцы-массивы в 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 раза в год)
> бухгалтер должен считать сам.
Или сильно трудолюбивый бухалтер, или просто софт невсеобъемлющий.
Что тут еще добавить?
← →
RDA (2003-04-16 11:21) [11]>>Соловьев
Это я понимаю, и частично буду делать расчеты на сервере.
← →
MsGuns (2003-04-16 11:38) [12]Разница есть и очень большая.
Для выборок в различные отчеты (а зарплата и делается в основном для них) требуется "шариться" по нескольким таблицам, связанным иногда косвенно. Если все это делать на клиенте, придется создавать кучу временных таблиц и тащить их на клиент, там же и обновлять. ХП делает это заметно эффективнее.
Кроме того, данные о начислении зависят еще и от таких напрямую не связанных с з/пл сущностей БД, как табель, структура подразделений с окладами и должностями, плановый фонд, график работы (календарь предприятия) и т.д. Если при расчете все это
по очереди извлекается с сервера и тащится на клиент, а том потом "переваривается", то эффективность этого процесса весьма низкая. По сравнению с логикой на сервере. Я уж не говорю о том, что при изменении любого алгоритма (а они меняются не реже, чем соотв.законодательства) придется лопатить все проги.
Малый пример: расчет квартальной (полугодовой) премии.
Для "клиентского" варианта придется неминуемо делать несколько выборок довольно большого числа записей лицевых, фонда времени и прочего. Только для того, чтоб потом в проге по нескольким таким НД вычислить по каждому челу только одну сумму. (Вариант "все в одном запросе" катит далеко не всегда).
Для "серверного" варианта пишется одна-две ХП, всю кухню выполняющие внутрях и возвращающие уже готовые данные для добавления в лицевые (которые, кстати, могут быть сделаны и в самих ХП)
Похожая схема при расчете отпускных или больничных. Только кол-во народа меньше, а схема та же.
← →
RDA (2003-04-16 11:50) [13]>>MsGuns
Если изменить вопрос так:
Как правильней организовать хранение информации о начисления и удержаниях по сотруднику за 12 месяцев отчетного периода.
← →
MsGuns (2003-04-16 12:59) [14]>RDA © (16.04.03 11:50)
Во-первых, откуда такой постулат - 12 месяцев ? Во-первых, их не хватит, к примеру, для ежегодного перерасчета подоходного налога в феврале месяце, т.к. нужен весь прошлый год и январь текущего для коррекции итоговой суммы возврата или доначисления.
Я не так давно (с неделю-две назад) подробно отвечал на этот вопрос, по-моему, какой-то девушке. Там даже приблизительные структуры таблиц приводил со всеми необходимыми связями. Поищи в прошлых неделях или в архивах форумов.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.05.05;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.006 c