Търся съвет

Здравейте, търся съвет идея ... въобще всичко, което би ми помогнало. Въведение - става въпшрос за база данни и програма за застрахователно дружество. В това дружество има записани определен брой хора и те ползват известни медицински услуги, грубо казано. Представете си стандартни master-detail tables. В master са ми категорите мед. услуги - например лабораторни изследвания, стоматологични услуги, гастроентерологични изследвания и т.н. В Detail таблицата са различните и конкретни услуги. Тези услуги всяка година имат различна цена. (Става въпрос за приблизително 10 000 records). В detail таблицата имам ено field - date, дето указвам откога започва валидността ( в случая е '01/01/2002'), и едно поле дето е цената. Ясно е че от 01/01/2003 датата трябва да стане (не става въпрос за update table_name set field_name), защото трябва да имам и предните записи. Ако се insert ноново, как по дяволите да стане това), после цената ще се въведе на ръка.
мм не знам до колко стана ясно...
(oracle 8i- client - server)
но ако можете дайте идея, щото 01/01/2003 скоро ще дойде и мъка ми е...

предварително мерси...

Не съм сигурен че разбрах точно какъв ти е проблема, ама ще се опитам да дам идея за това което съм разбрал
пиши си всички записи (и за новите дати) и после с заявка си вади тези който ти трябват.
select * from master,detail where detail.date=2003 and master.ID=detail.ID

не знам дали ме разбра, ама ако не си питай пак
ICQ:14048238

Има фирми които разработват застрахователен софтуер с години и както всяка друга ограма сисема никога не може да се каже че това ще е последната версия. Естествено такива системи струват стотици хиляди в зелено.
И както често се случва в българия някой лаик user решава че тая работа е много проста и че за по малко от половин година ще направи застрахователн софтуер. Евала моме.
Ама по добер си подай оставката още сега защото некадърността ти си личи и посъветвай шефовете си да си купят нещо истинско и работещо!

МММ, личи си че си адски любезен и знаеш как да даваш кураж - едно завидно качество.
Наистибна има фирми, които разработват застрахователен софуер. Но все пак този софтуер, до една степен е стандатрен, след това малко или много зависи от законодателството в дадената страна. След като става въпрос за законодателство се сещаш, че не става въпрос за "И както често се случва в българия някой лаик user решава че тая работа е много проста и че за по малко от половин година ще направи застрахователн софтуер."
А колкото до кадърността ми.... мм има кой и как да я оцени. Ти вместо да даваш( или май по-скоро да пишеш) такива мнения ли да го нарека, оценки ли да го нареха, подигравки ли да го нарека.... дай някаква идея.
Да се правиме на велики всеки го може....

Ама по добер си подай оставката още сега защото некадърността ти си личи и посъветвай шефовете си да си купят нещо истинско и работещо!

ами да не си ме разбрал. Гледай сега записите в детайл си ги имам и хората си бачкат с тях. За тия приблизително 10000 записа има дата за валидност 01/01/2002 и за всяка услуга - определена цена и други условия, които в случая не играят роля. От 01/01/2003 ще важат същите услуги, ноо с различна цена. За да стая по-ясно, например:
01/01/2002 - кръвно изследване - цена 5 евро.
01/01/2003- кръвно изследване - цена - 5,50 евро. Схващаш ли? Естествено искам да имам и двата записа.
Те това ми е проблема....

bezplatno

ostavi si snimka, ako mi haresa6 ste pomislia

java - the best language for server side programming

Neobhodima ti e druga tablica... W idealniq slu4ai ti trqbwa nowa tablica ot wida

ServicePrice (serviceID, ValidityDate, PriceValue)

Pak w idealniq slu4ai maha6 poleto data i cena ot tablicata s uslugi i wzima6 cenite ot tazi nowa tablica... Predpolagam 4e ti oba4e nemove6 ili pone ne iska6 da promenq6 na4alnata tablica, zatowa bih ti prepory4al da si naprawi6 pak podobna tablica, no w neq da pazi6 samo prednite ceni na uslugite, dokyto w originalnata ti tablica winagi 6te sy6testwuwa samo teku6tata cena. Po tozi na4in 6te pazi6 istoriqta na promqna na cenite i nqma da promenq6 originalnata tablica, no togawa dawa6 malko overhead na tezi koito izpolzwat bazata... Ako ti trqbwa cenata na edna usluga za dadena data, pyrwo trqbwa da se proweri w Detail tablicata dali tazi data e sled datata otkogato e walidna teku6tata cena na uslugata, ako ne e, togawa trqbwa cenata da se wzeme ot tablicata s istoriqta...

W idealniq slu4ai (ako promeni6 originalnata tablica) tazi prowerka 6te se izbegne i cenata za dadena data 6te se wzima samo e edno query ot nowata tablica...

Btw, move da ti swyr6i rabota tablicata s istoriq na cenite da ima ne samo edna data, ami dwe dati koito obrazuwat perioda na walidnost na tazi cena. Imaiki se predwid 4e qwno nqma da promenq6 cenata wseki de, zaluvawa si da ima6 malko izli6ni danni za da uskori6 izwli4aneto na cenite (koeto move bi stawa dosta 4esto)...

Защо просто не въведеш нови записи със съответните услуги, цени и дати. Изборът на цената за съответната услуга ще се прави в зависимост от текущата дата, което може да стане автоматично или ръчно от потребителя.
Мисля, че това е най-лесното решение в случая, разбира се можеш и да създадеш и нова таблица, където да детайлизираш нещата (както каза някой преди мен), но това е по трудоемко и може да се отрази на цялата структура.
Не знам как да се направи това конкретно в Oracle, но съм убеден , че има такава възможност.

Успех.

те това защо просто не въведеш ... е дето ме шашка... Как ще въведа 10 000 записа, нали не си представяш да напиша 10 000 insert into ... бла-бла..... това с детайл таблицата на детайла е гот като идея, само че не мога да променям началната структура на базата данни ( програмата, която работи в момента, просто не мога на този етап) сега като пиша ми дойде нещо на ум, я да видим дали и как ще се реализира..
.... та значи идеята ми е за всеки ред от мастер таблицата (демек група от сходни услуги) , отварям един cursor is select * detail_from table_name where code_master_table= нещо си. Селектвам си всичко де що принадлежи на таз групияка). Отварям си cursor бла...бла .. и insert into ... values (cursor.code_detail_table, cursor. description, '01/01/2003', t.n). И след това някой или някои от засрахователното дружество само коригира, демек въвежда новите цени и новите стойности на други параметри, за които няма смисъл да говорим. Така ми се струва, че хем избягвам хамалогията, запасвам си история на цени и т.н. глупости и самото дружество си въвежда цените...
Хм как ви се струва това .... дали ще стане? Сега ми хрумна...
Може да го обсъдим...

Доуточняване - Ясно е, че РК на детайл таблицата е от вида, categoryid, detailid, strat_date..

Troen kompoziten PK.
Evala mome evala!
Ama ne se prawiat taka nestata!

ми щом не се правят така нещата, как се правят?
Я ме открехни ... сподели...