|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
Уважаемые коллеги, я только начал изучать БД, поэтому заранее прошу прощения за ламерские вопросы. Маленькая преамбула: для распределения премии своим сотрудникам несколько лет пользуюсь собственноручно созданной таблицей в Excel, без макросов, но худо-бедно автоматизированной, на основе которой хочу написать ПО, которое бы помогло быстрее считать, распределять и и консолидировать данные по премии. В перспективе с возможностью получения статистики. Как это работает в реальной жизни: есть 100 сотрудников распределенных по 3 управлениям, которые в свою очередь делятся на 2-4 отдела. Премия на все подразделение в целом согласно нашему положению о премировании вычисляется как сумма следующих величин: ((оклад сотрудника * время в часах затраченное на проект) /число часов в месяце) * коэффициент премии. То есть, например: в месяце 160 часов. Некто Иванов с окладом 120 рублей отработал по проекту 1 - 80 часов (коэффициент за проект 1 был 0.3) и по проекту 2 - 80 часов (коэффициент за проект 2 был 0.4). Таким образом вклад Иванова в премию подразделения составил 120*80/160*0.3 = 18 рублей и 120*80/160*0.4 = 24 рубля. Итого 42 рубля. Из таких Ивановых сложилась общая премия подразделения в размере скажем 5000 рублей. Которая разделилась по управлениям в пропорции 2000-1600-1400 рублей (потом эти суммы руководитель управлений разделили по отделам, а начальники отделов распределили по сотрудникам и в сумме вышло те самые 5000 рублей, при этом пресловутый Иванов де-факто получит за проект 1 не 18, а 0 рублей,а за проект 2 не 24, а 30 рублей). Теперь, собственно, вопросы. Как правильно спроектировать БД, с учётом того, что. 1) должность у сотрудника может поменяться как в другом месяце, так и в середине месяца (то есть некий Петров по проекту 3 отработал 20 часов с окладом 120 рублей, а ещё 17 часов с окладом 137 рублей) 2) оклад у должности также может поменяться с течением времени. 3) каждый месяц/год - разное количество часов в месяце и разные проекты в этом месяце. 4) нужно будет собирать сатистику по Иванову/Петрову котрого за период сменилось 4 должности, а в каждой должности оклад по 2 раза менялся. Заранее спасибо за советы! ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2021, 14:33 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF, Вы не собираетесь попробовать сами что-нибудь сделать и показать результаты? Если вам дадут готовое решение, вы ничему не научитесь, а люди потратят время в наивной уверенности, что помогли вам, но вместо этого оказали медвежью услугу. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2021, 18:31 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF ... а начальники отделов распределили по сотрудникам и в сумме вышло те самые 5000 рублей, при этом пресловутый Иванов де-факто получит за проект 1 не 18, а 0 рублей,а за проект 2 не 24, а 30 рублей). я то думал будет вопрос - где и в каком месте Иванова нагрели (на.б@ли) на 10 рублей... как можно что-то собирать, вычислять, распределять, если начальники кладут в карман десятку или завтра двадцатку ??? Ну а так, для начала, можно почитать как устроен Табель учета рабочего времени в 1С... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2021, 20:37 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
vmag uGRAF ... а начальники отделов распределили по сотрудникам и в сумме вышло те самые 5000 рублей, при этом пресловутый Иванов де-факто получит за проект 1 не 18, а 0 рублей,а за проект 2 не 24, а 30 рублей). я то думал будет вопрос - где и в каком месте Иванова нагрели (на.б@ли) на 10 рублей... как можно что-то собирать, вычислять, распределять, если начальники кладут в карман десятку или завтра двадцатку ??? Начальники не распределяют премию себе. И не имеют возможности такой в принципе. А те самые 10 рублей от Иванова ушли Сидорову, который по проекту 1 отработал меньше времени, но его вклад в успешное завершение проекта больше чем у Иванова. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2021, 20:41 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
Вы даже не подозреваете сколько людей носят за пазухой кирпич с готовностью почесать вам им голову за ваши распределения.... uGRAF Премия на все подразделение в целом согласно нашему положению о премировании вычисляется как сумма следующих величин: ((оклад сотрудника * время в часах затраченное на проект) /число часов в месяце) * коэффициент премии. uGRAF А те самые 10 рублей от Иванова ушли Сидорову, который по проекту 1 отработал меньше времени, но его вклад в успешное завершение проекта больше чем у Иванова Сидоров пока Иванов работал час, поковырялся в носу всего 10 минут, но получил премию Иванова, потому что у него по формуле Оклад больше чем у иванова в 10 раз... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2021, 22:53 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
vmag Вы даже не подозреваете сколько людей носят за пазухой кирпич с готовностью почесать вам им голову за ваши распределения.... uGRAF Премия на все подразделение в целом согласно нашему положению о премировании вычисляется как сумма следующих величин: ((оклад сотрудника * время в часах затраченное на проект) /число часов в месяце) * коэффициент премии. uGRAF А те самые 10 рублей от Иванова ушли Сидорову, который по проекту 1 отработал меньше времени, но его вклад в успешное завершение проекта больше чем у Иванова Сидоров пока Иванов работал час, поковырялся в носу всего 10 минут, но получил премию Иванова, потому что у него по формуле Оклад больше чем у иванова в 10 раз... Знаете, я был уверен, что это форум про БД, а не про поиски вселенской справедливлсти. Вы совершенно не поняли принципов формирания и распределения (допускаю, что возможно я их не очень корректно описал) и пытаетесь критиковать? Ещё и ахинею про кирпичи несёте. Востину как в бородатом анекдоте. Чем отличаются русский, американский и еврейский форумы? - на американском форуме вы задаете вопрос и вам дают ответ - на еврейском форуме вы задаете вопрос и вам задают встречный вопрос - на русском форуме вы задаете вопрос и вам долго объясняют почему вы такой му**к. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 00:10 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Востину как в бородатом анекдоте. Чем отличаются русский, американский и еврейский форумы? - на американском форуме вы задаете вопрос и вам дают ответ - на еврейском форуме вы задаете вопрос и вам задают встречный вопрос - на русском форуме вы задаете вопрос и вам долго объясняют почему вы такой му**к. Данный анекдот это самая любимая вымышленная история обиженных на мир людей. На русском форуме людям реально пытаются помочь. ИМХО, в то же время именно русский человек знает и упоминает этот анекдот, так как русский человек -- часто лентяй и просто любитель халявы :) Он свято верит, что придя на англоязычный форум он припрется и будет просить выполнить за него работу, пусть это будут задания в универе, или задания на работе -- тут же выстроится толпа альтруистов, ещё и долларов в карманы насуют. Но почему же русский человек не топает попрошайничать помощи за бугром, это остаётся за кадром. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 00:48 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAFТеперь, собственно, вопросы. Как правильно спроектировать БД В общем-то - никак. Не пытайтесь спроектировать её "правильно", да ещё и с первой попытки. Делайте "хоть как-то", потом будете допиливать по ходу эксплуатации. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 01:23 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Как правильно спроектировать БД Делай в нормальной форме - всё будет правильно. uGRAF должность у сотрудника может поменяться как в другом месяце Таблица сотрудник, должность, период (год-месяц), дата начала (+дата окончания). uGRAF оклад у должности также может поменяться с течением времени. Таблица Должность, период, оклад. uGRAF каждый месяц/год - разное количество часов в месяце и разные проекты в этом месяце. Таблица проект, период, часы. uGRAF нужно будет собирать сатистику по Иванову/Петрову котрого за период сменилось 4 должности, а в каждой должности оклад по 2 раза менялся. Никаких проблем - обычная выборка с join. uGRAF То есть, например: Не забудь делать выхлоп так, чтобы сразу было понятно, кому и за что ты насчитал. Я бы вынес начисление за sql, чтобы было где развернуться и не изъеживаться, пытаясь из реляционных данных сделать расчётный листок. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 05:00 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Востину как в бородатом анекдоте. Про Пупу и Лупу. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 05:00 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF, Судя по Вашему посту и подходу Вы не айтишник, а владелец или приближенный к нему человек. Рекомендую отойти от дел несвойственных таковым, это будет лучше для Вас и бизнеса. Смотрите на задачи только со стороны бизнеса, а айтишную часть отдайте человеку посреднику между бизнесом и айти. Судя по тому, что у Вас ручное распределение мотивационных выплат и руководители стоят в стороне, то Вы имеете определенные преимущества перед другими. Их нужно правильно переосмыслить и развить, заодно проверив те моменты о которых пусть и грубо, но намекнули тутошние гоп... Анекдот верный, проверено не раз, но времена и накал страстей вносят свою лепту. Ответ на вопросы зашит в Вашем вопросе и не обязательно лезть в 1С. Я бы сказал крайне не желательно для Вас лично. Проверено практикой и электроникой. Основной учет необходимый для формирования правильной базы для расчетов в базе данных у Вас отсутствует полностью (судя по описанию задачи), потому решить задачу качественно у Вас не получится. Создавайте правильный табельный учет с учетом KPI по проектам и от него пляшите. Постарайтесь не потерять свои оргпреимущества при автоматизации. Вариант плана реализации где-то такой - качественный сбор данных для составления ТЗ - чего хочу и что есть - создание ТЗ можно по частям, базовая информация, расчет, выплаты, контроль эффективности. Дедуктивный или индуктивный метод это решать Вам - автоматизация документооборота - автоматизация расчетов - аналитика и обратная связь с документооборотом. Как-то так видится навскидку в столь раннее время дня ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 08:01 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
hVostt Данный анекдот это самая любимая вымышленная история обиженных на мир людей. На русском форуме людям реально пытаются помочь. ИМХО, в то же время именно русский человек знает и упоминает этот анекдот, так как русский человек -- часто лентяй и просто любитель халявы :) Он свято верит, что придя на англоязычный форум он припрется и будет просить выполнить за него работу, пусть это будут задания в универе, или задания на работе -- тут же выстроится толпа альтруистов, ещё и долларов в карманы насуют. Но почему же русский человек не топает попрошайничать помощи за бугром, это остаётся за кадром. Мне кажется, обиженный тут только Вы. Если Вам нечего сказать по делу - просто промолчите. Мир от этого станет лучше :-) crutchmaster Не забудь делать выхлоп так, чтобы сразу было понятно, кому и за что ты насчитал. Я бы вынес начисление за sql, чтобы было где развернуться и не изъеживаться, пытаясь из реляционных данных сделать расчётный листок. Определенно, начисление будет за пределами sql. Проблема в том, что я застрял именно на этапе проектирования БД. С учетом данных Вами советов, попробую переформулировать и сузить свои вопросы, ответы на которые возможно позволят мне уже не задавать другие: 1) Начну прям с самого малого. Допустим, есть таблица "Сотрудники", которая содержит значения в виде фамилий, имен, отчеств, табельных номеров и ID, в качестве первичных ключей. Пока про связи с другими таблицами пока даже не говорим. 7 месяцев эта таблица живет и в неё лишь попадают новые сотрудники изредка, а потом некая Сидорова выходит замуж и меняет фамилию (а потом проходит два месяца, она снова выходит и снова меняет фамилию). Собственно сам вопрос: Как правильно сделать таблицу "Сотрудники", чтобы сделав (потом, еще через год) запрос в БД о фактических премиях за 07.2021 я увидел: Сидорова (таб. № 321) - 30 рублей, за 08.2021: Сидорова-Водкина (таб. № 321) - 35 рублей, за 12.2021: Кузнецова (таб. № 321) - 32 рубля? Я склоняюсь к тому, что Сидорова, Сидорова-Водкина и Кузнецова, несмотря на то, что этот один и тот же человек, должны быть разными записями (с одинаковым значением табельных номеров, по которым я смогу потом делать запросы, как по интересующим меня значениям). Я прав или можно\нужно сделать как-то по другому и это будет более "мастхэвно"? 2) Связываем сотрудников, с должностями и окладами. Поскольку у человека может поменяться должность в любое время, а у должности оклад, в таблице "Должности" должны быть только должности и ID\Первичные ключи, в таблице "Оклады" - размеры окладов и ID\Первичные ключи, а таже мне придется сделать таблицу "Периоды", в которых значения будут представлять собой диапазоны дат (начало\окончание\ID). Диапазоны дат при этом не обязательно будут соответствовать календарному месяцу. Потом нужно будет связать с таблицей "Периоды" - таблицы "Сотрудники", "Должности" и "Оклады". Или не делать отдельную таблицу с периодами, а, сделать, как советуете Вы, просто завести период как один из атрибутов в таблицах "Сотрудники" и "Должности"? aleck_b uGRAF, Судя по Вашему посту и подходу Вы не айтишник, а владелец или приближенный к нему человек. Рекомендую отойти от дел несвойственных таковым, это будет лучше для Вас и бизнеса. Смотрите на задачи только со стороны бизнеса, а айтишную часть отдайте человеку посреднику между бизнесом и айти. Судя по тому, что у Вас ручное распределение мотивационных выплат и руководители стоят в стороне, то Вы имеете определенные преимущества перед другими. Нет совсем не владелец, и даже не приближенный просто зам. руководителя почти айтишного большого подразделения. Занимаемся внедрением CAD\CAM\CAE\PLM-систем. Это не основной бизнес предприятия, а поддержка основного бизнеса. aleck_b Основной учет необходимый для формирования правильной базы для расчетов в базе данных у Вас отсутствует полностью (судя по описанию задачи), потому решить задачу качественно у Вас не получится. Создавайте правильный табельный учет с учетом KPI по проектам и от него пляшите. Постарайтесь не потерять свои оргпреимущества при автоматизации. Алгоритм формирования и распределения есть. Застрял я именно на этапе проектирования БД. Выше, цитируя другое сообщение, переформулировал и сузил свои вопросы. У меня цель совсем банальная: сэкономить свое время на работу в Excel во время формирования премиального фонда. Раньше было проще, у нас проект был один скажем так, "Операционная деятельность", при этом неважно чем мы занимались, внедрением или поддержкой. ВПРом, я собирал данные из табеля (в том же Excel) и распределял премию по отделам примерно минут за 30. Потом за 15 минут подтягивал их обратно. Теперь одновременных проектов в течение периода больше 10, и уходит у меня совсем не полчаса. Так-то у меня и программисты есть в штате, но я эту программу планирую написать сам в свободное от работы время. Мне просто это интересно, хоть я и не программист по образованию, чуть самостоятельного изучения java, чуть-чуть python. aleck_b Вариант плана реализации где-то такой - качественный сбор данных для составления ТЗ - чего хочу и что есть - создание ТЗ можно по частям, базовая информация, расчет, выплаты, контроль эффективности. Дедуктивный или индуктивный метод это решать Вам - автоматизация документооборота - автоматизация расчетов - аналитика и обратная связь с документооборотом. Как-то так видится навскидку в столь раннее время дня Как писал выше, цель не настолько глобальная. В перспективе еще упростить работу табельщице, дать возможность сотрудникам смотреть статистику по себе, не анализируя бумажные квитки, и не обращаясь в бухгалтерию. Может даже с другими подразделениями этим ПО поделиться, у которых формирование премиального фонда схожим образом происходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 09:19 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Теперь, собственно, вопросы. Как правильно спроектировать БД, с учётом того, что. 1) должность у сотрудника может поменяться как в другом месяце, так и в середине месяца (то есть некий Петров по проекту 3 отработал 20 часов с окладом 120 рублей, а ещё 17 часов с окладом 137 рублей) 2) оклад у должности также может поменяться с течением времени. 3) каждый месяц/год - разное количество часов в месяце и разные проекты в этом месяце. 4) нужно будет собирать сатистику по Иванову/Петрову котрого за период сменилось 4 должности, а в каждой должности оклад по 2 раза менялся. Заранее спасибо за советы! Можно один к одному перенести вариант из Excel. При этом надо помнить, что большинство СУБД - это просто системы управления БД, и не имеют возможностей по построению пользовательского интерфейса. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 09:24 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
Stanislav P Можно один к одному перенести вариант из Excel. При этом надо помнить, что большинство СУБД - это просто системы управления БД, и не имеют возможностей по построению пользовательского интерфейса. Проблема в том, что Excel у меня каждый месяц новый, через "сохранить как" от предыдущего получаемый. Делать такую же структуру в БД не совсем целесообразно. Я прекрасно понимаю, что интерфейс - отдельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 09:31 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Как правильно сделать таблицу "Сотрудники", чтобы сделав (потом, еще через год) запрос в БД о фактических премиях за 07.2021 я увидел: Сидорова (таб. № 321) - 30 рублей, за 08.2021: Сидорова-Водкина (таб. № 321) - 35 рублей, за 12.2021: Кузнецова (таб. № 321) - 32 рубля? Я склоняюсь к тому, что Сидорова, Сидорова-Водкина и Кузнецова, несмотря на то, что этот один и тот же человек, должны быть разными записями (с одинаковым значением табельных номеров, по которым я смогу потом делать запросы, как по интересующим меня значениям). Я прав или можно\нужно сделать как-то по другому и это будет более "мастхэвно"? Это будет одна запись в таблице сотрудников и это будет несколько записей в таблице премий. При этом можно сделать так, что в каждый конкретный период времени будет отображаться актуальная информация о сотруднике на тот момент (фамилия и прочее) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 09:32 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
Stanislav P Это будет одна запись в таблице сотрудников Поясните пожалуйста немного поподробнее. Как в одной таблице могут\должны сосуществовать значения Сидорова-Водкина и Кузнецова с первоначально заведенной записью Сидорова? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 09:54 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Я прав или можно\нужно сделать как-то по другому и это будет более "мастхэвно"? Если вам нужно несколько ид - делайте. Много ид лучше, чем мало. В крайнем случае потом сгруппируете. uGRAF Поскольку у человека может поменяться должность в любое время, а у должности оклад, в таблице "Должности" должны быть только должности и ID\Первичные ключи, в таблице "Оклады" - размеры окладов и ID\Первичные ключи, а таже мне придется сделать таблицу "Периоды", в которых значения будут представлять собой диапазоны дат (начало\окончание\ID). Диапазоны дат при этом не обязательно будут соответствовать календарному месяцу. Таблица периоды - уже избыточна, там будут или связи 1 к 1, или бардак, когда надо что-то обновить. У нас, например, месячный период, просто целое, в формате YYYYMM, человекопонятный вариант, правда надо плясать, когда хочешь 2 периода до/после. Лучше - число месяцев с фиксированной даты, оно не такое понятное в сыром виде, зато легко преобразуется в то что надо и с ним удобно работать. Если надо что-то внутри периода - дата начало - дата окончания в самой таблице с данными. Тоже надо смотреть, чтобы периоды не пересекались, где не нужно. uGRAF Или не делать отдельную таблицу с периодами, а, сделать, как советуете Вы, просто завести период как один из атрибутов в таблицах "Сотрудники" и "Должности"? Так проще. Еще надо исходить из того, что всё будет copy-on-write для того, чтобы было доступно что там было раньше. Советую во избежание будущих разборок удаляемым/обновляемым записям менять статус или скидывать в backup-таблицу и везде сделать поле "дата модификации" и поле "пользователь", если бд будет использовать больше одного человека. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 10:08 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Так-то у меня и программисты есть в штате, но я эту программу планирую написать сам в свободное от работы время. Как определите какая будет схема данных (это практически готовый скелет тз), можете идти их напрягать насчёт сервера для бд и чтобы писали всякие морды/отчёты/начислялки под всё это дело. Нахрен вы их держите в конце концов. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 10:12 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Stanislav P Это будет одна запись в таблице сотрудников Поясните пожалуйста немного поподробнее. Как в одной таблице могут\должны сосуществовать значения Сидорова-Водкина и Кузнецова с первоначально заведенной записью Сидорова? Бессмысленно спрашивать - вы не понимаете самых основ проектирования БД. Это все равно что ученику, который не знает букв дать задание прочитать книгу. Откройте для начала хоть для приличия что-то по основам проектирования БД, чтобы хотя бы понимать что вам тут пишут ) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 10:14 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Поясните пожалуйста немного поподробнее. Как в одной таблице могут\должны сосуществовать значения Сидорова-Водкина и Кузнецова с первоначально заведенной записью Сидорова? Можно извратиться и сделать отдельно таблицу с биологическими человеками и отдельно с паспортными данными, куда и сваливать все их ФИО с актуальными датами. А там, хоть выбирайте всё сразу, хоть ставьте флаг actual и выбирайте только актуальное фио сотрудника. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 10:16 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
Serguei Бессмысленно спрашивать - вы не понимаете самых основ проектирования БД. ТС что-то да понимает. Тут бывают люди, которые понимают еще меньше, для них вся эта нормализация и связи - вообще пустой звук и таблицы там все одинаковые +200 полей в каждой про запас. Но тем ни менее, им ничего не мешает 30 лет юзать у себя на производстве какой-нибудь акцесс и получать за это деньги. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 10:17 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Поясните пожалуйста немного поподробнее. Как в одной таблице могут\должны сосуществовать значения Сидорова-Водкина и Кузнецова с первоначально заведенной записью Сидорова? В упрощённом виде это делается так: в таблице сотрудников хранится только последнее значение фамилии. В таблице "Предыдущие значения" хранятся все предыдущие значения фамилий с датами окончания их действия. Когда делается выборка за период, в который попадает смена фамилии, то правильные значения на дату берутся из таблицы предыдущих значений. PS. Проектирование БД с таким функционалом нетривиально. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 10:39 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
crutchmaster Как определите какая будет схема данных (это практически готовый скелет тз), можете идти их напрягать насчёт сервера для бд и чтобы писали всякие морды/отчёты/начислялки под всё это дело. Нахрен вы их держите в конце концов. Ну во-первых мне и без того, есть чем их загрузить по основному фронту работ, а во-вторых я же писал, мне самому это интересно :-) crutchmaster Так проще. Еще надо исходить из того, что всё будет copy-on-write для того, чтобы было доступно что там было раньше. Советую во избежание будущих разборок удаляемым/обновляемым записям менять статус или скидывать в backup-таблицу и везде сделать поле "дата модификации" и поле "пользователь", если бд будет использовать больше одного человека. Stanislav P В упрощённом виде это делается так: в таблице сотрудников хранится только последнее значение фамилии. В таблице "Предыдущие значения" хранятся все предыдущие значения фамилий с датами окончания их действия. Когда делается выборка за период, в который попадает смена фамилии, то правильные значения на дату берутся из таблицы предыдущих значений. PS. Проектирование БД с таким функционалом нетривиально. crutchmaster, Stanislav , спасибо огромное! Получается и для должности мне тоже правильнее всего завести один оклад, и таким же образом вести историю его изменений! А все-таки эти историй изменений целесообразно вести в отдельных таблицах или (если мы, например, говорим от таблице "Сотрудники") помимо полей фамилий, имен, отчеств, табельных номеров и ID можно завести поле "Изменения фамилии" и при изменении фамилии записывать туда (при срабатывании триггера изменения в поле "Фамилия") последнее (до изменения) значение поля "Фамилия" и дату изменения. Получится, что в поле "Изменения фамилии" будет хранится строка вида "01.08.2021|Сидорова;01.09.2021|Сидорова-Водкина", а запрос потом можно будет делать через условие, обращаясь к полю "Изменения фамилии", только если мы хотим получить информацию не на текущую дату и если значение "Изменения фамилии" не пустое, в противном же случае обращаться к полю "Фамилия". ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 11:50 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF Получится, что в поле "Изменения фамилии" будет хранится строка вида "01.08.2021|Сидорова;01.09.2021|Сидорова-Водкина", а запрос потом можно будет делать через условие, обращаясь к полю "Изменения фамилии", только если мы хотим получить информацию не на текущую дату и если значение "Изменения фамилии" не пустое, в противном же случае обращаться к полю "Фамилия". Можно и так. Вариантов версионирования (хранения изменений) существует много. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 12:28 |
|
Как правильно спроектировать БД для ПО, которое будет распределять премию
|
|||
---|---|---|---|
#18+
uGRAF А все-таки эти историй изменений целесообразно вести в отдельных таблицах Если они совсем не нужны, то можно выкидывать в архивные. Если подразумевается, что архивные данные должны попадать в выборку наряду с актуальными, то так делать не стоит, иначе придётся из прицеплять, а зачем это надо. uGRAF Получится, что в поле "Изменения фамилии" будет хранится строка вида "01.08.2021|Сидорова;01.09.2021|Сидорова-Водкина" Лучше отдельные записи делать с фио и всей фигнёй и отдельные ключи для паспортных данных и для человека, а потом связывать. Такие структуры типа таблица в таблице в поле через запятую - не нужны, с ними потом ничего нельзя сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2021, 12:53 |
|
|
start [/forum/topic.php?fid=32&msg=40045338&tid=1539814]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
135ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 255ms |
0 / 0 |