Re: Database design

True, there is EDI. But not every partner of an international company can afford to integrate it into their hereditary systems. Further, I was told there are countries where you do not even have postal codes like Senegal.

In my former company (digital pay-tv) we only had to deal with Germany and Austria. That began to become difficult as we had several addresses per customer: one address for the location of the equipment (the default address), one address for the invoice sent to (you may have several per customer because not everybody wants his blue movies appear on the invoice sent to his family), one country code for the broadcast provider because the Germany and Austria are fed by different cable providers. We considered using EDI but we just were shocked by the amount of work involved. It would have taken years to integrate just parts of it, especially the invoicing (we thought of outsourcing collection services).

Further experience with so-called standards:

1. once upon a time there was a standard DIN 66052 for volume headers on GCR tapes. The only company that did it was Siemens with the consequence that these tapes could not be processed by the very common IBM mainframes. So we did not use it as it would lead to less flexibility.
2. HBCI for quite safe electronic banking is nice but astonishingly no bank in Germany realises it because it is very general and very much work. Instead you have a variety of workarounds (SSL, HTTP-S, S-HTTP, IPSec, SHTML, ...). Why? Because it takes too long to implement it.
3. ANSI-92 for SQL. All the database manufacturers do not exceed the entry level of compliance. Why? Not of sufficient interest for database manufacturers (they would loose the advantage of their proprietary enhancements), not for the programmers (they would have to change their proprietary hacks towards a immature implementation) and not for the customers (as they want a working solution, not a standardized one).
4. SCSI-2 is very widespread and "standardized". Try to run your Sun Sparc with a non-certified SCSI-2 drive in production as a database server.

Martin

Kenneth C Stahl wrote:
>
> Steve McDaniels wrote:
> >
> > I participate in lot's of dialogue about this sort of thing
> > (dealing with direct marketing)
> > and I would like to offer a couple of additional
> > suggestions (after reading the threads on this):
> >
> > My org. captures world-wide consumer product registrations.
> > We have in place several mechanisms to validate the data,
> > name and primarily address information, supplied to us.
> > US addresses - no problem
> > Canadian addresses - some problem
> > Mexican addresses - very difficult
> > South American address - very very difficult
> > French addresses - very difficult
> > UK addresses - difficult
> > German - not yet being done
> > Asian (China/Japan/Indonesia) - not even planned!
> >
> > We do this because
> > 1) we find little value in storing "contacts"
> > who have given us an invalid email address, mail address,
> > and/or telephone number (i.e., cannot be "contacted")
> > 2) once validated, we can associated multiple parties at the
> > same location (for consumers, this means "household").
> >
> > By far, our consumer database (15 million registrations by 10 million names
> > in
> > 9 million households) consists primarily of
> > North American consumers + French + UK
> >
> > With the current CRM fad, where it is often desirable to
> > obtain consumer "contact" info directly from the consumer,
> > we have researched and are considering developing real-time
> > address (US) validation (re: CASS from USPS) which would
> > not validate an address but would give us a "very likely good"
> > ZIP + 4 plus default mail stops.
> >
> > I would be very (very!) interested in knowing what references,
> > links, etc. you come up with (develop?) about these
> > world-wide "standards".
> >
> > BTW: See also ISO stuff about country codes
> > or yell-mail me for copy
> >
> > Kenneth C Stahl <BlueSax_at_Unforgetable.com> wrote in message
> > news:387CA134.D26FB1BF_at_Unforgetable.com...
> > > I have a rather odd request, but hopefully someone who reads this
> > newsgroup
> > > will know what I am looking for.
> > >
> > > I am in the process of designing a database from scratch based solely on
> > > the types of things that the customer is going to need.
> > >
> > > Since I don't have any previous database to reference I have to come up
> > > with the sizing of attributes for each of the entities.
> > >
> > > For example, I know that I will be dealing with an entity called a
> > CONTACT.
> > > One of the attributes for this contact will be an address. This address
> > can
> > > have several lines such as Suite, Street address, Room number, etc. etc.
> > > plus city, province/state, postal code, etc.
> > >
> > > Is there any univeral standard that defines attributes such as this? I
> > want
> > > to make my CITY attribute big enough to accomodate any possible city in
> > the
> > > world, but I don't want to make it too large. Also, while postal codes in
> > > the U.S. are 5-digits, I know that in other countries it is typically
> > > longer than that - so I would want to accomodate the largest possible
> > > postal code. For phone numbers I know that I'll have to deal with a
> > country
> > > code, an area code, an exchange/prefix and then the number as well as a
> > > possible extension. What I want to avoid is designing my database to only
> > > work with U.S. addresses and phone numbers.
> > >
> > > Although I've never actually worked with EDI myself, I have heard that it
> > > has established a standard for common attributes. Is this true? If so,
> > > would this be a reasonable standard to use?
>
> So far I have been under-whelmed by the responses. I had thought that the
> whole thing of standardization would be so ingrained by now that scores of
> people would come forward with references to documented standards and that
> basically all of these peple would ultimately cite pretty much the same
> materials.
>
> What I have found is that a lot of places have internal (and therefore
> proprietary) standards but that there doesn't seem to be any universal
> standard. I had even thought that in the world of EDI there might be a
> standard set forth and no one has made any references to that either.
>
> It makes me start to wonder how companies that do a great deal of
> international business handle such things.
>
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
> .................................................
Received on Thu Jan 20 2000 - 09:02:56 CST