Are have duplicates so bad?

[andreainpanama]

Again, my small backpackers hostel located in Panama is keeping my wheels
spinning.

Now I am beginning to wonder. Is it so bad to have duplicates in my guest
list?

What's the harm in having 15 "Brittney Spears" in my guest list? If they
are actually different Brittneys, well then I can differentiate between them
by using their passport numbers and nationalitys.

If they are in fact, the same exact Brittney, well then, the dates of stay
will be different, and that is also helpful to know.

And the chances of there being two Brittney Spears in my hostel from the
exact same country at the exact same time are close to nil.

My normal traffic flow here is the hostel is as follows,

The majority of guests (50%) come and stay a night or two, then leave, and I
never see or hear from them again. Thus their names are not of interest.

The next group of guests (35%) are travelling around my area for about a
month, and since we are in a large city, they use us as a jump off point.
They come back and forth to the hostel, a day here, a day there, and then
eventually, they leave and I never see or hear from them again. So other
than the time they are here, their names are not of interest. (But one never
knows when someone will fall into the following category.)

The next group of guests (15%) are people who stay with us and come back say
three to six months later, even up to 2 or 3 years later! These are the most
likely to slip through the cracks if they are duplicates, because I don't
remember faces for that long.

But really, it is not a big deal to me.

So the idea is that if I type in Brittney Spears, and I am allowed to add
her to my guest list, even though it is a duplicated name, it will still be
clear in the reports because of her dates of stay, that she was the same
Brittney that stayed with us on 4 different occasions.

Allowing dupes in my guest list will simplify my life, since I still have
not figured this out and it is over two months working on this.

Am I forgetting some important issue that will come back to haunt me?

 

[Jeff Boyce]

If you do not care to know when you have a "repeat customer" (i.e.,
duplicate names), why are you even saving the names?

If you can uniquely identify PersonA, from the UK, with passport number
1234567890, then you don't NEED to have duplicates. You can open the table
with that information and set a unique index on those three fields.

Or am I not understanding your situation?

--
Regards

Jeff Boyce
Microsoft Office/Access MVP


Microsoft IT Academy Program Mentor
http://microsoftitacademy.com/

Microsoft Registered Partner
https://partner.microsoft.com/

 

[mnature]

Why use Access to keep track of guests? Have a book where guests sign-in.
Have a column in that book that they can check, that asks if they have stayed
at your establishment before. Make an Excel file with a row for each day.
Label the columns as "number of first-time guests" and "number of returning
guests." Update these columns when it is convenient for you, by looking in
your guest book.

 

[andreainpanama]

I LOVE THE IDEA of adding a column to my physical guest sign in list, asking
if they have stayed with us before. This is an excellent double check
system, and since they must sign my guestbook anyway, this takes no time at
all. What a wonderful suggestion!!!

Yes, as Jamie suggested I still should have all names and personal data for
"the authorities." Should some kind of incident occur or should a parent be
looking for their missing in action backpacking child, it is important to
have the info, not for me personally, but as a precaution.

As I continue to read up on relational database structure, I am beginning to
conclude that in order to get even close to the 3rd normal form (I can't
believe I even have that phrase in my vocabulary now....), I should strive to
create my database to not have duplicates, even though it doesn't personally
matter to me.

 

[mnature]

Most places I have stayed require me to show some sort of identification. I
usually show the same ID each time, and I would suppose that most people do
that. So when someone signs in, you still ask for their ID, but use that as
the distinguishing label in case of multiple names. In the case where there
is no ID (I suppose that might happen) a country/county/state of origin would
probably settle the matter.

There really is no problem having duplicate names, because they are
referring to different individuals. As long as you have some way of
distinguishing between individuals who may happen to have the same name, you
are not really breaking 3rd normal form. What you should strive for, is to
not have duplicate records that refer to the same object, whether that object
is a person, place or thing. For instance, you could have a number of guests
that stay on the same day. But it is not a problem to put the same date down
a number of times. Otherwise you would need a lookup table of all possible
dates for having guests.

So, having the same guest stay twice, and putting their name down twice in
your guest table, would be against 3rd normal form. But if you set up your
database to make it easy to determine if someone is already in the system (or
simply ask them if they have stayed there before), you can avoid having them
listed twice. And if there is another guest of that name, a quick question
or looking at ID will sort out which guest this is.

Always make the database do the work for you. Have it do all the sorting
and filtering and looking up of information.

 

[Tim Ferguson]

I should strive to
create my database to not have duplicates, even though it doesn't
personally matter to me.

That last phrase is one of the most important things about any database
design.

If you _really_ don't care about individuals, then don't bother to model
them. If you _know_ that you will never want to know about people who
have come back again; or if you don't have any business benefit in
telling one John Smith from another one (or, recognising two John Smiths
as the same person): then just forget about the whole layer of
complexity. Most of us would look at such a business model and shake our
heads, because much of the time it's not true; but only you know what
your requirements are and how they are likely to evolve. Much of DB
design is about double-guessing future needs and that is why you are
being pushed toward a People table with identifiers and foreign keys and
so on. But that does not mean we are right!

Just a thought... <g>


Tim F

 

[mnature]

The analogy that comes to my mind is a database that has tables for

employees and customers respectively: the same person could appear once
in each table however they are not duplicates in the data model because
there is no 'person' entity, only customers and employees which are
distinct entities.

It sounds like the database in question is modelling 'guests' rather
'people' and that 'the same guest' is distinct from 'the same person'
in the data model. Finding out whether two guests are the same person
is perhaps a query with some fuzzy logic and a 'confidence' rating,
rather than something essential to the day-to-day business of room
bookings.

Jamie.

It reminds me of something I was once told. There is an expression that "If
it is worth doing, it is worth doing well." I was told that there was a word
left off of that expression. The word is "enough." I believe that, in this
case, the owner of the hostel only needs to verify "well enough" that a
particular guest is the same person as a former guest.

If something occurs that requires interacting with local authorities, then
it does look better (such as on the 10:00 news) if your records look official
and well-organized.

 

[andreainpanama]

I really appreciate all the feedback.

There is no question for many reasons, I want to store the names of my
guests in my database, so identifying them solely by an id number is not an
option. The only question was whether I would set up the database to allow
duplicate guest records. I will incorporate some of these ideas and let you
know how it turned out.

Thanks!!!