A
Amy Blankenship
That's one way to do it. What if someone changes his/her citizenship 
?
?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
A
Amy Blankenship
I could talk by Microsoft Messenger. E.mail me at amy at magnoliamultimedia
dot com, and I'll send you details.
-Amy
dot com, and I'll send you details.
-Amy
A
Amy Blankenship
Craig Alexander Morrison said:Well no what the OP actually wants is....
<<<<To present real and true financial and marketing data to perspective
buyers
of my business.
To answer my guests questions, eg, "How many guests have you had?" "What
country are the majority of your guests from?" "How many Swiss visitors
have
you had?" "Are most of your guests under 30?" etc.>>>>
Did you read that, I think the OP is more concerned about data consistency
than you are.
And I think you're not at all concerned about actually answering Andrea's
question. If you were, you would address her and her question rather than
expending a lot of energy trying to demonstrate that I gave her a wrong
answer.
If you are SO concerned for her and her data integrity, post a solution she
can use rather than nitpicking at mine. Otherwise stay out of the way so I
can direct my energy to helping her fine tune rather than responding to your
posts which have ZERO point in the context of this thread other than to hear
yourself talk.
A
Amy Blankenship
I am not aware if there is something like an Access Jobs board. Maybe
someone else has more information on that.
someone else has more information on that.
C
Craig Alexander Morrison
I am of the "published" opinion the database design by email is dangerous if
not actually irresponsible.
I am also quite happy to point out when someone is giving information that
will harm a design, such as your lack of measures, which I had initially
only suspected, to prevent data duplication and endanger integrity and
consistency.
I have since had to correct a series of further errors from you and me (g).
not actually irresponsible.
I am also quite happy to point out when someone is giving information that
will harm a design, such as your lack of measures, which I had initially
only suspected, to prevent data duplication and endanger integrity and
consistency.
I have since had to correct a series of further errors from you and me (g).
C
Craig Alexander Morrison
Andrea,
Database Design by Email is dangerous.
I would suggest you consider a few approaches:
1. Learn a bit about Relational Database design. (The main thing to
concentrate on is the process of Relational Data Analysis (aka
Normalisation))
Come back to the newsgroup with specific questions about particular
problems with the database AND the application(s)
2. Consider employing a local developer.
3. Consider employing a developer who can at least make a personal visit to
collect the user requirements and collate the data sources (current forms,
reports, spreadsheets, register) and sit down and talk through your
requirements.
4 Consider employing a remote developer
In cases 2, 3 and 4 get references, check with their previous clients and
look at samples of the work they have done. There are many many cowboys
around who be little more than users themselves who think they know what
they are doing.
Whatever approach make sure you own the source code so that you can tweak
the design in future either in-house or with another developer.
5. You could try the newsgroups but they are really best suited to an answer
to a specific question
If you go with this approach make sure you evaluate all the answers and note
any disagreements between other posters, this will assume that you have
learnt a little bit more about Relational Database Design.
If you are fairly confident in the process of creating forms and reports you
may just get the developer to create the database and you can do the
applications.
6. Check to see if anyone in the same line as you has done something similar
and see if you can make a mutually acceptable arrangement.
BTW Concentrate on getting the database design correct (or as correct as you
can) before worrying about Forms, Reports etc. You cannot get out of a
database what you do not put in.
Let your watchwords be Data Integrity and Data Consistency and ensure that
the developer is as concerned as you about the accuracy of your data.
Duplicate data is a killer to any system, and more so if it contains
important financial information.
BTW Keep this a secret, designing a good relational database is actually
rather straightfoward, if you understand the business (or rather the data
and how the business uses the data) and how to normalise data.
Using Access to create the applications becomes so much easier once you have
a good relational database design . Access is still one of the best tools to
design applications that use relational databases.
Database Design by Email is dangerous.
I would suggest you consider a few approaches:
1. Learn a bit about Relational Database design. (The main thing to
concentrate on is the process of Relational Data Analysis (aka
Normalisation))
Come back to the newsgroup with specific questions about particular
problems with the database AND the application(s)
2. Consider employing a local developer.
3. Consider employing a developer who can at least make a personal visit to
collect the user requirements and collate the data sources (current forms,
reports, spreadsheets, register) and sit down and talk through your
requirements.
4 Consider employing a remote developer
In cases 2, 3 and 4 get references, check with their previous clients and
look at samples of the work they have done. There are many many cowboys
around who be little more than users themselves who think they know what
they are doing.
Whatever approach make sure you own the source code so that you can tweak
the design in future either in-house or with another developer.
5. You could try the newsgroups but they are really best suited to an answer
to a specific question
If you go with this approach make sure you evaluate all the answers and note
any disagreements between other posters, this will assume that you have
learnt a little bit more about Relational Database Design.
If you are fairly confident in the process of creating forms and reports you
may just get the developer to create the database and you can do the
applications.
6. Check to see if anyone in the same line as you has done something similar
and see if you can make a mutually acceptable arrangement.
BTW Concentrate on getting the database design correct (or as correct as you
can) before worrying about Forms, Reports etc. You cannot get out of a
database what you do not put in.
Let your watchwords be Data Integrity and Data Consistency and ensure that
the developer is as concerned as you about the accuracy of your data.
Duplicate data is a killer to any system, and more so if it contains
important financial information.
BTW Keep this a secret, designing a good relational database is actually
rather straightfoward, if you understand the business (or rather the data
and how the business uses the data) and how to normalise data.
Using Access to create the applications becomes so much easier once you have
a good relational database design . Access is still one of the best tools to
design applications that use relational databases.
M
mnature
There is some professional software that already exists. I googled on
"hostel software" and these were on the first page. I chose them because
they both seem to have demo versions. Even if you have someone program a
database for you, it is good to have some standard to judge it by. Also, you
may find they have some functionality that would be nice, other than just for
tracking your clients.
http://www.hotel-software.com/
http://www.dustysoftware.co.nz/
"hostel software" and these were on the first page. I chose them because
they both seem to have demo versions. Even if you have someone program a
database for you, it is good to have some standard to judge it by. Also, you
may find they have some functionality that would be nice, other than just for
tracking your clients.
http://www.hotel-software.com/
http://www.dustysoftware.co.nz/
A
Amy Blankenship
If you're of the opinion that database design via forum is unwise, then
perhaps your best bet is to unsubscribe from a forum where that is the
purpose.
perhaps your best bet is to unsubscribe from a forum where that is the
purpose.
C
Craig Alexander Morrison
If you're of the opinion that database design via forum is unwise, then
While people like you are giving advice on database design I hope that many
will point out your amateur errors and profound lack of knowledge. I would
have though with such a profound lack of knowledge you may wish to educate
yourself, perhaps, and sadly, not.
Learn from good "non-product" specific books about relational database
design not from dodgy websites. Check the points I raised with you in these
books and see if I am wrong.
You seemed more concerned with my motives, well my motives are transparent I
wanted to correct serious errors in the advice you were giving. I will be
around from time to time and will happily criticise points that are just
plain wrong. I gave you the benefit of the doubt on my first post, I have no
doubts about you at all now.
Relational Data Analysis requires a thorough understanding of the problem
domain not some person making wild assumptions like you have done on this
thread. Database Design by email is dangerous because you have to ensure
that the Client is disclosing all the relevant information, they may not
know that they are not. The collection of sources for the RDA process will
throw up a lot of questions that the skilled developer will ask of the
Client.
You do not have appear to have the necessary rigour to be advising people
about database designs. Throughout this thread you have failed to address a
series of salient points, I had hoped you had accepted them, but it would
appear you are not equipped to argue your point not that it would have made
sense anyway as you are wrong, and I only looked at one table and you sadly
confirmed that you would have taken no steps to void data duplication and
cared little for the data integrity and consistency of the database.
Your failings can be corrected with a little bit of education, I hope you
will consider this.
As I said at the beginning I do not want to get into the Surrogate vs
Natural Key debate, but you will find that most of the people who do
advocate the use of Surrogate Keys (in all tables) will also ensure that the
Natural Key (when available) is implemented as a Unique Non-Null Index.
perhaps your best bet is to unsubscribe from a forum where that is the
purpose.
While people like you are giving advice on database design I hope that many
will point out your amateur errors and profound lack of knowledge. I would
have though with such a profound lack of knowledge you may wish to educate
yourself, perhaps, and sadly, not.
Learn from good "non-product" specific books about relational database
design not from dodgy websites. Check the points I raised with you in these
books and see if I am wrong.
You seemed more concerned with my motives, well my motives are transparent I
wanted to correct serious errors in the advice you were giving. I will be
around from time to time and will happily criticise points that are just
plain wrong. I gave you the benefit of the doubt on my first post, I have no
doubts about you at all now.
Relational Data Analysis requires a thorough understanding of the problem
domain not some person making wild assumptions like you have done on this
thread. Database Design by email is dangerous because you have to ensure
that the Client is disclosing all the relevant information, they may not
know that they are not. The collection of sources for the RDA process will
throw up a lot of questions that the skilled developer will ask of the
Client.
You do not have appear to have the necessary rigour to be advising people
about database designs. Throughout this thread you have failed to address a
series of salient points, I had hoped you had accepted them, but it would
appear you are not equipped to argue your point not that it would have made
sense anyway as you are wrong, and I only looked at one table and you sadly
confirmed that you would have taken no steps to void data duplication and
cared little for the data integrity and consistency of the database.
Your failings can be corrected with a little bit of education, I hope you
will consider this.
As I said at the beginning I do not want to get into the Surrogate vs
Natural Key debate, but you will find that most of the people who do
advocate the use of Surrogate Keys (in all tables) will also ensure that the
Natural Key (when available) is implemented as a Unique Non-Null Index.
A
Amy Blankenship
And then how do you tell Jean Dupont of Paris from Jean DuPont of Dijon?
A
andreainpanama
Well, this postings seems to have caused quite a stir....36 responses and
counting!!!...but yet most of the stuff is going right over my head, and as a
few of you commented...I didn't want my posting to become the brunt of a
theoretical battle!
After continuing my research, I am now thinking that perhaps my design
problems might be resolved by making my Guest Info and Bookings Table, many
to many relationship. Eg, 1 room can have more than one guest at any given
time and
1 guest can have many different bookings in the course of any given time.
If the consensus is yes, I should have many to many, are there any
suggestions as to how I can manipulate my existing setup to fit a new one?
Please keep the answers easy, I am a little dislexic when it comes to all
this theory and new vocabulary.
If you prefer, I can start a new post with my new question.
Thanks so much!
counting!!!...but yet most of the stuff is going right over my head, and as a
few of you commented...I didn't want my posting to become the brunt of a
theoretical battle!
After continuing my research, I am now thinking that perhaps my design
problems might be resolved by making my Guest Info and Bookings Table, many
to many relationship. Eg, 1 room can have more than one guest at any given
time and
1 guest can have many different bookings in the course of any given time.
If the consensus is yes, I should have many to many, are there any
suggestions as to how I can manipulate my existing setup to fit a new one?
Please keep the answers easy, I am a little dislexic when it comes to all
this theory and new vocabulary.
If you prefer, I can start a new post with my new question.
Thanks so much!
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.