WHats Your Definition Of A Big Enough War Chest??

[milanbenes]

OH,

my definition only applies to folks who have taken 100% responsibility for their pension situation and not subscribed to the traditional 'pension product from a financial institution'. Agreed, people with a traditional pension product, are, hmmm, how best to say it,,, not in control of their destiny.

Milan.

[milanbenes]

'I disagree.
I see the warchest in SQL based application terms, where the warchest becomes a temp table , but only exists when it is drawn upon.

i.e. it is different from the main table because it is disposable and has different properties.
'


EO, if I understand, you War Chest then is mutually exclusive from the Pension fund main table and as such when calculating the current total value of the pension fund you do not take into consideration the war chest temp table as under your rules this would be false accounting against the pension fund ?

Milan.

[OrangeHopper]

I agree with your sentiment. Unfortunately I started my pension when I was a nipper, well before I got a role helping to write a pension quotation system.

[EternalOptimist]

EO, if I understand, you War Chest then is mutually exclusive from the Pension fund main table and as such when calculating the current total value of the pension fund you do not take into consideration the war chest temp table as under your rules this would be false accounting against the pension fund ?

Milan.

The main table has a different PK and set of indexes, that would never fly on a temp table. Once the temp table is fully populated, all future records go into the main table, which always gets bigger.
If queries are made on the temp table, there will be enough data to last for x months. As x approaches 0, disaster recovery procedures are implemented so that the main table remains uncorrupted.

[milanbenes]

hat off, perfect


Milan.

[TheFaQQer]

The main table has a different PK and set of indexes, that would never fly on a temp table. Once the temp table is fully populated, all future records go into the main table, which always gets bigger.
If queries are made on the temp table, there will be enough data to last for x months. As x approaches 0, disaster recovery procedures are implemented so that the main table remains uncorrupted.

Surely the best way to do it would be to have a materialized view which selected data from both the temporary table and the non-temporary table, refreshed either periodically or on commit (probably on commit, so you could get real-time data analysis going to see how much you had left).

Of course, the main downside of using a temporary table is that one big crash and it's wiped out completely.

[bandit_legs]

alright let's put some perspective on this, how much do we need,

it actually ties in very well with the subject of how much do we need to retire on

i reckon today it costs about x,000's euros a month for my household to live nicely

i'd like to retire with a fund providing y,000's euros a month

therefore, the two tie into each other

and for example, your war chest, well isn't it actually inherited by your pension fund ?

dig into your war chest you're digging into your pension fund

as to when can I retire ?

well that's when I have a fund which will sustain a debit of y'000's euros per month, until the end of my life

Milan.

in the 8yrs of contracting ive never voluntarliy been on the bench for longer than 1 month. I have always allowed a war chest to cover me for min: 3 months on the bench - with a reality that it usually take 1 month to find a contract.

althought its worth saving enough for say 6-12 months cover, i never really forsee myself being out of work for 1 whole year!?!

id love to know if there is anyone out there who has actually been unemployed and unable to find work for a full 12 months sat in their dressing gown in the bench???!

[EternalOptimist]

id love to know if there is anyone out there who has actually been unemployed and unable to find work for a full 12 months sat in their dressing gown in the bench???!

do you like camping

[rootsnall]

The main table has a different PK and set of indexes, that would never fly on a temp table. Once the temp table is fully populated, all future records go into the main table, which always gets bigger.
If queries are made on the temp table, there will be enough data to last for x months. As x approaches 0, disaster recovery procedures are implemented so that the main table remains uncorrupted.

I've renamed the temp table as 'Non Working Mrs Low Tax' table and set parameter X at 2 yrs. If X > 2 yrs then insert into table Main.

For table Main, if X > Y then 'F*** It, I'm off to Benidorm'.

The question is, what value do we assign to Y ?

[shoes]

I compare contracting with an alternative of permanent employment.

If you draw funds from your company that mean your take home in any given financial year is greater than your take home would have been in an equivilent permie role then your contracting has been worthwhile. From a financial perspective.

A fund (that is the combination of your after tax money held in your name plus what you can draw in future from your company whilst allowing for tax liabilities) that lasts years would be nice. But unrealistic for most of us.

We're all doomed with regard to providing for our retirement. If you aren't taking time away from the office of months at a time between contracts you may as well have stayed permie.