DB size?
- Thread starter Franknstuff
- Start date
R
Rich
Guest
...therefore I must be ?Mile-O-Phile said:
M
Mike375
Guest
Mile-O-Phile said:
I can't see any point to it, at least for the way things run here.
Firstly, while we have computers networked each computer runs the data base as a stand alone item and with its own set of records. One computer runs 5 salesman and basically covers the various things that happen from an initial cold call through interviews where a first appointment was obtained plus the various administration and various product comparison letters.
The data base is backed up as whole unit to a CD ROM about every 60 to 90 minutes as are about 50 letters that are stored which are run from the data base.
My limited understanding is that by having front and back end that someone can do work on the data base while it is being used.
Mike
Mike - you are probably right by saying that "outsiders" to the insurance companies don't understand the processes and environment well enough and, therefore, design interfaces that do not meet the needs of the business. Also - it sounds like your understanding of the environment and need allows you to create interfaces that are valuable to your chosen professiona and that is great so.... I think it would be really valuable to you and possibly a career designing these systems for sale in the future if you did some studying on normalization, the normal forms, and relational database design. There is a TON of info on this website on these topics and you can gain a lot of knowledge from here...
Please DO NOT interpret this as an attack on you as that is not my intention - I'm simply trying to suggest to you what I and others here feel would benefit you... There are also a large number of books available on Amazon that deal with this topic - My Suggestion: The first book I read on the subject of database normalization was titled: Information Modeling and Relational Databases - from cenceptual analysis to logical design by Haplin, Morgan, & Kaufmann. It covers all the basics and some of the more advanced theory as well...
HTH and good luck to you...
p.s. I would suggestion splitting the database and having all FE w/ interface on each terminal with one backend - this way there is no data reconciliate the data at a later date - but this is your choice...
Kevin
Franknstuff
More I know Less I know
- Local time
- Today, 01:27
- Joined
- Apr 28, 2004
- Messages
- 54
This got me
"My limited understanding is that by having front and back end that someone can do work on the data base while it is being used.
Mike"
Am I reading this right?
If anybody wants to make me feel better I have a question under forms that I could use an answer.
"My limited understanding is that by having front and back end that someone can do work on the data base while it is being used.
Mike"
Am I reading this right?
If anybody wants to make me feel better I have a question under forms that I could use an answer.
Rakier
Registered User.
- Local time
- Today, 08:27
- Joined
- Mar 21, 2002
- Messages
- 75
Mike,
I understand your point of view...if it ain't broke, then why fix it. It works for you and that is the most important thing. However, you have to understand that the folks here are trying to help, not attack. Just because something works doesn't make it right.
I have one big database that I first created several years ago using macros and stuff because that was how I first learned things. Then I discovered this forum and the wonders of code. I completely redesigned the db and it worked much...much...much better after that, mainly due to things I found out on this forum. Did the old version work...yes. Was it right....no. Did the new version work better....yes. Since that time, I have redesigned sections of the db and am in the process of doing a complete redesign. Like I said...it has been working for 3 years and working well. But...I have learned new and better ways of doing things during that time and want the dB to take advantage of those new things.
Like Pat said earlier...it is about learning. I constantly am learning new ways to do this or that and try to take advantage of them. I have learned ways to change my 20 lines of code into 10. Even though things work, it doesn't mean that they should stay static. Everything must change over time.
I am not a "professional" developer by any stretch of the imagination. But...that doesn't mean that I don't respect those who are and listen to their ideas and bits of wisdom. Is everything they say taken as the absolute best way? No...but it never hurts to try their ideas out.
Remember, you must evolve...learn new ways. I really do not think that the way that you have designed your dB is the best way to do it. I think that you could benefit from the advice given by Pat, Miles and Rich. I know that I have benefited many times over from their words of wisdom. I know that this would involve a huge paradigm shift for you...as well as a large amount of work to redesign the dB. This may not be of any interest to you. After all, it works. But...in the long run, the advice given by all here would give you a system that worked better and faster and would be way easier to maintain.
I know this from past experience. I took their advice and have a system that works lightyears better than what I had before.
Just my two cents.
I understand your point of view...if it ain't broke, then why fix it. It works for you and that is the most important thing. However, you have to understand that the folks here are trying to help, not attack. Just because something works doesn't make it right.
I have one big database that I first created several years ago using macros and stuff because that was how I first learned things. Then I discovered this forum and the wonders of code. I completely redesigned the db and it worked much...much...much better after that, mainly due to things I found out on this forum. Did the old version work...yes. Was it right....no. Did the new version work better....yes. Since that time, I have redesigned sections of the db and am in the process of doing a complete redesign. Like I said...it has been working for 3 years and working well. But...I have learned new and better ways of doing things during that time and want the dB to take advantage of those new things.
Like Pat said earlier...it is about learning. I constantly am learning new ways to do this or that and try to take advantage of them. I have learned ways to change my 20 lines of code into 10. Even though things work, it doesn't mean that they should stay static. Everything must change over time.
I am not a "professional" developer by any stretch of the imagination. But...that doesn't mean that I don't respect those who are and listen to their ideas and bits of wisdom. Is everything they say taken as the absolute best way? No...but it never hurts to try their ideas out.
Remember, you must evolve...learn new ways. I really do not think that the way that you have designed your dB is the best way to do it. I think that you could benefit from the advice given by Pat, Miles and Rich. I know that I have benefited many times over from their words of wisdom. I know that this would involve a huge paradigm shift for you...as well as a large amount of work to redesign the dB. This may not be of any interest to you. After all, it works. But...in the long run, the advice given by all here would give you a system that worked better and faster and would be way easier to maintain.
I know this from past experience. I took their advice and have a system that works lightyears better than what I had before.
Just my two cents.
M
Mike375
Guest
Rakier
As you said the time to make the changes is a real sticking point and doubly so when the thing works.
Another issue is that you might just prefer to do things certain ways. For example, the issue that was mainly discussed on this thread about using 20 tables instead of one table is something that I just prefer. With the 20 categories of prospect for telemarketing it just makes me happy to have it as virtually 20 separate data bases that funnel the results into a central section.
But also I think that data bases are like some other things in life. On one hand you have the enthusiast and for some others things are just a means to an end.
I am very interested in firearms and participate on a couple of gun forums. Now in that area I am probably the counterpart of Pat and Rich. However, the majority of posters on those forums basically have the gun as a means to an end. You find the same deal with car owners.
Like yourself I have often thought about going through this data base and cleaning some things up but time is the killer.
Mike
As you said the time to make the changes is a real sticking point and doubly so when the thing works.
Another issue is that you might just prefer to do things certain ways. For example, the issue that was mainly discussed on this thread about using 20 tables instead of one table is something that I just prefer. With the 20 categories of prospect for telemarketing it just makes me happy to have it as virtually 20 separate data bases that funnel the results into a central section.
But also I think that data bases are like some other things in life. On one hand you have the enthusiast and for some others things are just a means to an end.
I am very interested in firearms and participate on a couple of gun forums. Now in that area I am probably the counterpart of Pat and Rich. However, the majority of posters on those forums basically have the gun as a means to an end. You find the same deal with car owners.
Like yourself I have often thought about going through this data base and cleaning some things up but time is the killer.
Mike
R
Rich
Guest
Bit like the modern day car and a steam driven one then eh?
M
Mike375
Guest
Rich said:
Funny you mention that because I have always been interested in steam engines
Rakier
Registered User.
- Local time
- Today, 08:27
- Joined
- Mar 21, 2002
- Messages
- 75
I agree that there are definitely preferences to ways to doing things. I have some differences between the way that I name variables during coding and that which is "standard". That's okay though. We're all gonna have some things that we prefer over things that others prefer.
My problem was that the post seemed to be degenerating into a "my way" vs "your way" free for all. The experienced members of the forums (and probably what you would call enthusiasts
) were taking time out of their day to do something which they thought was helpful to you. You took their advice as "attacks" against your methods. I don't think that was their intentions at all. They were merely pointing out that your method is not considered the "proper" method for doing things...even though it works. It's kinda like building a car. You can use the wrong types of lugnuts to hold the tires on, but eventually the tires will get loose and fall off. I think that is the same thing they were trying to say about your dB. Even though it works now and everything's wonderful, eventually you are going to run into a problem. I have found several problems with the old dB that I designed and even though I designed workarounds for them, I knew they would eventually return to bite me in the a**. That's why I proactively redesigned the thing and am doing it again. This way, I can take the time while the production model works fine rather than having a major crisis and rushing with fixes.
My problem was that the post seemed to be degenerating into a "my way" vs "your way" free for all. The experienced members of the forums (and probably what you would call enthusiasts
) were taking time out of their day to do something which they thought was helpful to you. You took their advice as "attacks" against your methods. I don't think that was their intentions at all. They were merely pointing out that your method is not considered the "proper" method for doing things...even though it works. It's kinda like building a car. You can use the wrong types of lugnuts to hold the tires on, but eventually the tires will get loose and fall off. I think that is the same thing they were trying to say about your dB. Even though it works now and everything's wonderful, eventually you are going to run into a problem. I have found several problems with the old dB that I designed and even though I designed workarounds for them, I knew they would eventually return to bite me in the a**. That's why I proactively redesigned the thing and am doing it again. This way, I can take the time while the production model works fine rather than having a major crisis and rushing with fixes.
M
Mike375
Guest
Rakier
I agree that there are definitely preferences to ways to doing things. I have some differences between the way that I name variables during coding and that which is "standard". That's okay though. We're all gonna have some things that we prefer over things that others prefer.
We agree
My problem was that the post seemed to be degenerating into a "my way" vs "your way" free for all. The experienced members of the forums (and probably what you would call enthusiasts ) were taking time out of their day to do something which they thought was helpful to you. You took their advice as "attacks" against your methods. I don't think that was their intentions at all.
Go back to the start of the thread. I did no more than respond to the thread starter's question.
They were merely pointing out that your method is not considered the "proper" method for doing things...even though it works.
But there are reasons why it works. Give me at least some credit. I am 56 and have been in the insurance business since I was 22. You must know that the insurance companies and banks ar all computer based. Do you have any idea of how many "Pat Hartmans" have looked at this data base? Do you have any idea of how many times I have heard "I see what you mean" or "That changes things"
My data base is not a piece of shit!!!!
The issue of having one table instead of 20 tables does not work. I have been through that. One of the attractions of this data base for telemarketing is that it updates Results Vs Goals as you complete each call and click Next Prospect. Selecting results from one big table slows things down as the you mobe through the calls.
I am not at all saying that Pat Hartman and others could not make the data base better BUT most of their criticism is misplaced. Again, commonsense should tell you that given I am in the insurance business and make stuff for one insurance company...then I am not operating on some island..
It's kinda like building a car. You can use the wrong types of lugnuts to hold the tires on, but eventually the tires will get loose and fall off. I think that is the same thing they were trying to say about your dB.
That is something I would like someone to elaborate on for me. This data base today is essentially the same as it was in 1999/2000. I am assuming that the data base is not like a car in the sense that it "wears out"
Even though it works now and everything's wonderful, eventually you are going to run into a problem.
Again, elaborate for me. What will be the problem or problems?
These loose general statements don't help me.
"I have found several problems with the old dB that I designed and even though I designed workarounds for them, I knew they would eventually return to bite me in the a**. That's why I proactively redesigned the thing and am doing it again. This way, I can take the time while the production model works fine rather than having a major crisis and rushing with fixes."
Again, elaborate for me on what sort of problems I will encounter.
I just did a quick check on some of the forms, macros and queries and the latter part of 1999 was when they were made. So we have been running for 4.5 years.
I do make changes each week or so but they usually only involve opening a different form etc.. From March 2004 until the end of may 2004 I had to add quite a lot because of gov't regulations in Australia that relate to the selling of various financial products. I might also say that our DB is doing it all while the bigger groups are "still in transit" and have Word Templates as a "fill in"
Mike
I agree that there are definitely preferences to ways to doing things. I have some differences between the way that I name variables during coding and that which is "standard". That's okay though. We're all gonna have some things that we prefer over things that others prefer.
We agree
My problem was that the post seemed to be degenerating into a "my way" vs "your way" free for all. The experienced members of the forums (and probably what you would call enthusiasts ) were taking time out of their day to do something which they thought was helpful to you. You took their advice as "attacks" against your methods. I don't think that was their intentions at all.
Go back to the start of the thread. I did no more than respond to the thread starter's question.
They were merely pointing out that your method is not considered the "proper" method for doing things...even though it works.
But there are reasons why it works. Give me at least some credit. I am 56 and have been in the insurance business since I was 22. You must know that the insurance companies and banks ar all computer based. Do you have any idea of how many "Pat Hartmans" have looked at this data base? Do you have any idea of how many times I have heard "I see what you mean" or "That changes things"
My data base is not a piece of shit!!!!
The issue of having one table instead of 20 tables does not work. I have been through that. One of the attractions of this data base for telemarketing is that it updates Results Vs Goals as you complete each call and click Next Prospect. Selecting results from one big table slows things down as the you mobe through the calls.
I am not at all saying that Pat Hartman and others could not make the data base better BUT most of their criticism is misplaced. Again, commonsense should tell you that given I am in the insurance business and make stuff for one insurance company...then I am not operating on some island..
It's kinda like building a car. You can use the wrong types of lugnuts to hold the tires on, but eventually the tires will get loose and fall off. I think that is the same thing they were trying to say about your dB.
That is something I would like someone to elaborate on for me. This data base today is essentially the same as it was in 1999/2000. I am assuming that the data base is not like a car in the sense that it "wears out"
Even though it works now and everything's wonderful, eventually you are going to run into a problem.
Again, elaborate for me. What will be the problem or problems?
These loose general statements don't help me.
"I have found several problems with the old dB that I designed and even though I designed workarounds for them, I knew they would eventually return to bite me in the a**. That's why I proactively redesigned the thing and am doing it again. This way, I can take the time while the production model works fine rather than having a major crisis and rushing with fixes."
Again, elaborate for me on what sort of problems I will encounter.
I just did a quick check on some of the forms, macros and queries and the latter part of 1999 was when they were made. So we have been running for 4.5 years.
I do make changes each week or so but they usually only involve opening a different form etc.. From March 2004 until the end of may 2004 I had to add quite a lot because of gov't regulations in Australia that relate to the selling of various financial products. I might also say that our DB is doing it all while the bigger groups are "still in transit" and have Word Templates as a "fill in"
Mike
Up till now, everyone has tried to be extremely politically correct.
There comes a time when we just have to call a spade a spade.
There’s really no point in debating this as a programming issue.
What we’re looking at here is ego and divine ignorance.
Mike apparently took Access for Dummies 101 and at that point
his programming education came to a halt.
He was introduced to macros, thought they were neat and, at that
point, decided to quit learning. The fact that his application
contains no modules says it all.
Bottom line:
- Mike possesses no coding skills and doesn’t want to be
encumbered with any.
- Mike is clueless when it comes to database design. His ego
tells him otherwise so there’s no point in trying to educate him,
he’s hopelessly ignorant and that’s the way he wants to remain.
Bob
There comes a time when we just have to call a spade a spade.
There’s really no point in debating this as a programming issue.
What we’re looking at here is ego and divine ignorance.
Mike apparently took Access for Dummies 101 and at that point
his programming education came to a halt.
He was introduced to macros, thought they were neat and, at that
point, decided to quit learning. The fact that his application
contains no modules says it all.
Bottom line:
- Mike possesses no coding skills and doesn’t want to be
encumbered with any.
- Mike is clueless when it comes to database design. His ego
tells him otherwise so there’s no point in trying to educate him,
he’s hopelessly ignorant and that’s the way he wants to remain.
Bob
R
Rich
Guest
takes about as much time to maintain as your db ehMike375 said:Funny you mention that because I have always been interested in steam engines
M
Mike375
Guest
raskew said:
Bob,
These are the books I have:
Using Access 95 by Roger Jennings
Access 95 Unleashed Dwayne Giffor, et al
Running Microsoft Access for Windows John L Viescas and Microsoft Press. I also have the same book for Excel, Word and Powerpoint
And of course the Access Help material.
You said:
"Mike possesses no coding skills and doesn’t want to be
encumbered with any."
You are right. I don't need to be encumbered.
Mike
M
Mike375
Guest
Bob,
I do have one module but I have it in a another data base. Do you remember this I have this in a calculated field
AgeAtDeath: Agecount6([DOB],[DOD])
To run the following:
I do have one module but I have it in a another data base. Do you remember this
I have this in a calculated fieldAgeAtDeath: Agecount6([DOB],[DOD])
To run the following:
Code:
Function Agecount6(ByVal pdob As Date, _
Optional ByVal pEdte As Variant, _
Optional ByVal pWhat As Variant) As String
'************************************************* ****
'Purpose: Display age or difference between
' two dates with options to display
' in any variation of years, months,
' days.
'Coded by: raskew
'Inputs: 1) ? Agecount6(#3-Mar-80#) 'defaults
' to current date & "ymd" display
'
' 2) ? Agecount6(#3-Mar-80#, "4/25/04")
' Uses PEdte in place of date(),
' and default "ymd" display
' 3) ? Agecount6(#3-Mar-80#, "4/25/04", "d")
' Same as 2), but with display as days
'
'Output: 1) 24 years, 1 month, 15 days
' 2) 24 years, 1 month, 22 days
' 3) 8819 days
'************************************************* ****
Dim dte2 As Date
Dim dteMyDate As Date
Dim intHold As Integer
Dim n As Integer
Dim strHold As String
Dim strHold2 As String
Dim strTemp As String
Dim strWhat As String
strWhat = IIf(IsMissing(pWhat), "ymd", pWhat)
dteMyDate = pdob
dte2 = IIf(IsMissing(pEdte), Date, pEdte)
For n = 1 To Len(strWhat)
strHold = Mid(strWhat, n, 1)
Select Case strHold
Case "y"
intHold = DateDiff("yyyy", dteMyDate, dte2) + _
(dte2 < DateSerial(Year(dte2), Month(dteMyDate), Day(dteMyDate)))
dteMyDate = DateAdd("yyyy", intHold, dteMyDate)
strHold2 = strHold2 & LTrim(Str(intHold)) & " year" & IIf(intHold <> 1, "s, ", ", ")
Case "m"
intHold = DateDiff("m", dteMyDate, dte2) + (Day(dteMyDate) > Day(dte2))
dteMyDate = DateAdd("m", intHold, dteMyDate)
strHold2 = strHold2 & LTrim(Str(intHold)) & " " & "month" & IIf(intHold <> 1, "s, ", ", ")
Case "d"
intHold = DateDiff("d", dteMyDate, dte2)
strHold2 = strHold2 & LTrim(Str(intHold)) & " " & "day" & IIf(intHold <> 1, "s", "")
End Select
Next n
Agecount6 = strHold2
End Function
Last edited by a moderator:
R
Rich
Guest
Mike375 said:
You already are with the db you have
KenHigg said:
LOL....
To put this in perspective:
I work in state government (US) and we maintain a human resource management database that contains all the HR details (pay, empy. history, refferals, personal status, complete benefit detail, stock options, retirement packages, etc... for over 50,000 people that is EXTREMELY complex, has millions of records, spans 10 servers, client-server interfaces, web interfaces, etc... is fully normalized (Oracle RDBMS) and it has around 100 tables....
I'd personally really like to see Mike db so that we could all try to help him normalized his data so he can see the forest through the trees...
Kev
M
Mike375
Guest
KenHigg said:
Many of you seem to have missed the point that I made earlier, that is, the data base is in reality several data bases in one.
In the life/disability insurance area people who buy or "hire" professionally made data bases will have the following types
Premium quote system.
Product comparison and product assessment/ratings
Client management
Telemarketing data bases
Gov't compliance requirements for the insurance and financial services industries
Accountancy type data base for income tax and business expense purposes.
I have all of the above in my data base.
There are many advantages having it the one .mdb file. For example the telemarketing part is able to produce the various product comparisons and gov't compliance that we need for the prospect in question.
I am very well aware that the number of tables can be reduced but I prefer to have different tables. A simple example. When prospects are called then certain outcomes mean the prospects are deleted from the main table and appended to other tables. Now I could have all those appended to the one table and queries could separate the various categories of call outcomes. However, I choose to have different tables. On the other hand a bulk of prospects are held in one table for all categories and macros and queries replace records in the main table as they are used.
I will illustrate a part of the data base that is easy to illustrate and then you can tell me where I am wrong.
There are many tables with the following main fields.
Policy Feature..Company A Wording...Company B Wording...Differences
There are several other fields for dates, times and so on but the above four fileds are the key ones.
I have a table for each Company. However, the product comparitor uses a single table and when a Company is selected then the records in the table are appended to the table that the product comparitor uses.
The product comparisona set up so that Company A is the superior policy. However, at different times we will present a comparison where Company A is second best. This often depends on the parameters set for the comparison. I simply make a copy of one of the tables. In each table there are two spare fields. I simply copy and paste the fields with the policy wordings for each feature into the two spare fields. I then copy and paste them back so that they are reversed. The "differences" I then need to write out. For me this is a much easer operation than if all the product material for each company was in the one table. I am well aware that I could do all of the above with query to separate out one group. But I would need a lot of queries.
Just because I cook fish with bread crumb does not mean that I am unaware of grilled fish and the health benefits of grilled fish as compared to deep fried fish done in bread crumb.
99% of the time spent on this data base (by me) is doing what I am doing at present. That is entering policy wording data and key policy differences because of changes in the products by insurance companies. I always have this done within a couple of days of product changes. On the other hand the professionally made product comparitors are invariable one month later and that is preceded by an email warning you that the data on policy ABC is no longer current.
Mike
Mile-O
Back once again...
- Local time
- Today, 08:27
- Joined
- Dec 10, 2002
- Messages
- 11,316
Do you not even feel that Access 95 is lacking so many features compared to the late{r/st} version{s} of Access?
What about support? Should your database [no will; just should] pack in and die then who are you going to call to fix it? This is a question of technological support too.
And, then there's size. A database does have a maxium size (2GB in A97 upwards - I don't know about A95) and all these extra object definitions will be contributing to that size.
What about support? Should your database [no will; just should] pack in and die then who are you going to call to fix it? This is a question of technological support too.
And, then there's size. A database does have a maxium size (2GB in A97 upwards - I don't know about A95) and all these extra object definitions will be contributing to that size.
