$18 Million - To re-design recovery.gov website? (drugs, problems, world)

[sanrene]

I provided NOTHING MORE than a few pieces of data which needed to be manually keyed.

I stated NOTHING about the database itself, except an obvious suggestion for a primary key.

I made no mention of what tables would be used, or how they would look.

Based on those few pieces of data that would need to manually keyed - yeah, that's what I'm saying. In a well designed DB, they would never be entered that way. It was your example of how duplicates might enter a database and the need for cleansing. My point was that NO WAY would that be allowed to happen in an application that adheres to the relational model. Your example, not mine.

And you sincerely believe that because I said values A, B, C and D need to be keyed in, that somehow, I am also indicating the actual structure of the tables these values will be located?

I can only surmise that the example is one you are familiar with because it might be the way things are done in your shop. You still seem to be missing the point - it was your example of a possible scenario that I was responding to. In your scenario, one does not need to see the entire structure to know that what you put up as an example would be extremely slip-shod, poor design, just the little you have highlighted speaks volumes. You have no idea how often I have seen scenarios just as you describe - and since you seem to be conversant with "cleansing" processes, I can guess that is what you are used to dealing with.

I repeat .... TOTALLY RIDICULOUS !!!

You started with an example, I agree, the example you gave is totally ridiculous, but not unheard of.

And yes ... it would be FEASIBLE for both records to be entered, because there is no way of knowing whether they are the same company or not.

The two companies have SIMILAR names ... but not IDENTICAL.

Sorry, no it wouldn't. Because of the similarities, this one would be put aside to be checked. How do I know this? Way back when, that was my job.

If the two examples I provided turned out to be TWO COMPLETELY DIFFERENT COMPANIES ... then how would you enter the name and address just ONE TIME ???

That is not the argument you were making - your argument and the example were given to show how duplicates might enter a DB. IF it were 2 different companies, they would not have the same address and name - this would go in the pile - to check. Two different companies with basically the same name and address, as in your example, would not be allowed in the first place. It would be checked first.

I think I've repeated myself enough times about this already.

Me too.

[RD5050]

Originally Posted by sanrene

Based on those few pieces of data that would need to manually keyed - yeah, that's what I'm saying. In a well designed DB, they would never be entered that way. It was your example of how duplicates might enter a database and the need for cleansing. My point was that NO WAY would that be allowed to happen in an application that adheres to the relational model. Your example, not mine.

A data entry person receives a document.

The document contains a name, an address, and a dollar amount.

What is so unusual about it?

Have you ever heard of a SALES TRANSACTION ????

Or is this type of document too unfamiliar to you ?

It will likely also include information about the products, sales date, etc.

I can only surmise that the example is one you are familiar with because it might be the way things are done in your shop. You still seem to be missing the point - it was your example of a possible scenario that I was responding to. In your scenario, one does not need to see the entire structure to know that what you put up as an example would be extremely slip-shod, poor design, just the little you have highlighted speaks volumes. You have no idea how often I have seen scenarios just as you describe - and since you seem to be conversant with "cleansing" processes, I can guess that is what you are used to dealing with.

Yes, Data Cleansing is a process I am extremely familiar with, because I have dealt with it many times on many projects.

You see ... Data Cleansing is one of the most important processes that large companies use to maintain extremely enormous data warehouses in the "real world".

Maybe you'd like to read up on it:

Data cleansing - Wikipedia, the free encyclopedia

Data Scrubbing

And there is absolutely NOTHING about the design of a SALES TRANSACTION document that has ANYTHING to do with the structure of the database tables the data will eventually populate.

You started with an example, I agree, the example you gave is totally ridiculous, but not unheard of.

Sorry, no it wouldn't. Because of the similarities, this one would be put aside to be checked. How do I know this? Way back when, that was my job.

Ridiculous? Then you obviously never worked with extremely large customer databases.

That kind of thing happens all the time in large companies, when customer information is manually keyed at POS terminals by sales clerks, or is fed in from outside companies.

That is not the argument you were making - your argument and the example were given to show how duplicates might enter a DB. IF it were 2 different companies, they would not have the same address and name - this would go in the pile - to check. Two different companies with basically the same name and address, as in your example, would not be allowed in the first place. It would be checked first.

Maybe you should research a little into financial company names, because banks can operate under many similar names for their various businesses.

They can have one business which specifically deals with savings and loans, another for investments, another for credit cards, another for mortgages. And all may operate out of the same building.

Regarding the Obama / Client issue:

Maybe this might help you:

http://usa-the-republic.com/revenue/...ory/Chap6.html

Are theAmerican people sovereigns OVER the government? Or are they subjects of the government, UNDER the government's jurisdiction and power?


Important points. Sovereign Americans are above the governments they delegated management powers to. Governments are artificial persons, legal fictions. Governments, as artificial persons, can own property and incur debts on their own, separate from the sovereign people. The personal fortunes of the sovereign people are not to be used to discharge the government's debts. Governments have complete power over their OWN property and subjects. All jurisdiction implies superiority of power. All subjects UNDER the jurisdictional power of a government, are objects of taxation. As the Supreme Court stated above, a free man is subject to human laws only because he binds himself. You, as one of the joint owners of this country, have agreed to abide by certain laws, that you have agreed to. These laws are designated in the Constitution.

[thebigr]

Do not have time to read through all the posts and sort of glad I don't but anybody in there right mind knows it does not take 18 million to re-design any website.

Oh I forgot, the government is doing it, they will probably need an additional 5 million before it is all done.

[sanrene]

A data entry person receives a document.

The document contains a name, an address, and a dollar amount.

What is so unusual about it?

Have you ever heard of a SALES TRANSACTION ????

Or is this type of document too unfamiliar to you ?

It will likely also include information about the products, sales date, etc.

You still don't get it, which leads me to believe you have no idea about the underlying DB schema. You are looking at that document as if that is the actual structure of a table within a DB - it's not, or it should not be.

You think all that information is going to be stored in one table? NO WAY.

When the DE clerk enters the custid, it is then validated (i.e., is it already in the cust table), then enters the product the cust is ordering, the product is validated (i.e., is it in the prod table).

The cust file contains ONLY data related to the cust (id,name-address,etc) NO sales transactions. The prod table contains only data related to prod (id,decript,amt,cost). A saletrans contains only data related to the sale.

Under your example, a salestrans would include cust name, address, etc.

I think you are confusing what you are looking at in a particular paper transaction and not realizing the data is being retrieved from and stored in multiple tables.

You see ... Data Cleansing is one of the most important processes that large companies use to maintain extremely enormous data warehouses in the "real world".

I think I mentioned a while back that data warehouses allow a high degree of redundancy as a trade-off for speed and performance.

Maybe you should research a little into financial company names, because banks can operate under many similar names for their various businesses.

They can have one business which specifically deals with savings and loans, another for investments, another for credit cards, another for mortgages. And all may operate out of the same building.

Not likely. There a certain functions and transactions a bank has authority for that other aspects of the business do not. I would think it rare to have different business entities within a corporation that have the same name.

I see you continue to move the goal post. We were discussing YOUR little example, not how often banks or other financial entities hail from the same address or have the same name.

Regarding the Obama / Client issue:

Maybe this might help you:

I thought you said your previous post was the last word on this subject. Instead, you are scouring the internet trying to prove your point.

You and I will never agree on this issue. You did say obama was the client and then posted a passage that says the government is the client - you understand then that obama is not?

Maybe this might help you:

This is what you come with? Some kook-fringe website?

[RD5050]

Originally Posted by sanrene

You still don't get it, which leads me to believe you have no idea about the underlying DB schema. You are looking at that document as if that is the actual structure of a table within a DB - it's not, or it should not be.

You think all that information is going to be stored in one table? NO WAY.

First .... WHERE (please show me) do I mention ANYTHING about DATABASE design for the Sales Transaction document .... other than my below quote ????

And there is absolutely NOTHING about the design of a SALES TRANSACTION document that has ANYTHING to do with the structure of the database tables the data will eventually populate.

Did you notice the word tableS above? Pay particular attention to the "S" on the end of the word. It is there FOR A REASON. It means PLURAL. The data will not be stored in ONE TABLE ... as you seem to want to IMPLY.

Second ... ONCE AGAIN ... I am talking about a PIECE OF PAPER used for data entry ...NOT a DATABASE. I never even get into discussing how the Sales Database will look. So don't TRY TO IMPLY that I am bringing up DB design, by my simply providing you an example of a SOURCE OF DATA. You are the one who feels the need to discuss my "piece of paper" in database terms. To me ... it is simply a piece of paper with information on it ... and nothing more. This information can be scribbled on a napkin for all I care. I am not discussing the database aspects of it.

If it is so important to you to see how a Sales Transaction Database will look, here is a partial example:

Customer Table
Customer ID
Customer Name
Customer Address
Customer Phone Number

Sales Transaction Header Table
Customer ID
Sales Date
Store Number
Register Number
Transaction Number
Payment Type (cash/credit)
Credit Card Number


Sales Transaction Details Table
Customer ID
Sales Date
Store Number
Register Number
Transaction Number
Line Item Number
Merchandise Dept
Merchandise Class
Merchandise Style
Merchandise SKU
Quantity
Sales Amount

Additional tables can also be used if the database will allow for more complex data (multiple phone numbers for a customer, multiple payment types within a single transaction, etc.)

When the DE clerk enters the custid, it is then validated (i.e., is it already in the cust table), then enters the product the cust is ordering, the product is validated (i.e., is it in the prod table).

The cust file contains ONLY data related to the cust (id,name-address,etc) NO sales transactions. The prod table contains only data related to prod (id,decript,amt,cost). A saletrans contains only data related to the sale.

Under your example, a salestrans would include cust name, address, etc.

I think you are confusing what you are looking at in a particular paper transaction and not realizing the data is being retrieved from and stored in multiple tables.

You have got to be kidding me ????

Do you always talk this way to experienced database developers ???

It's like you are trying to prove you know simple arithmetic, by teaching me how to count to 10. The word "duh" comes to mind!

And just for the record... the Sales Clerk who is working at the POS terminal in the store DOES NOT KNOW the Customer ID.

Customer ID is an internal number known only to the database system, and may appear on reports used by management and corporate employees. It is not known by customers or sales clerks in the stores. It is a meaningless sequentially assigned number that is used as a common key field to join customer tables together when needed.

The Sales Clerk in the store can enter the customer's name, phone number, or credit card number, and potentially, this will find a matching customer record, assuming the POS (point-of-sale) system has real-time online access to the customer database. Not all POS systems have this available.

Under that scenerio, if the full information is found, it is verified between the clerk and the customer (i.e. do you still live at 123 Main St.?) Otherwise the clerk has to key the customers information into the system.

If online access was critical, then how would store's conduct business when the internet connection was down? Stores have to be able to function with or without internet access. It's not like they can just tell customers to leave, and close the store, because the internet connection was unavailable.

Not likely. There a certain functions and transactions a bank has authority for that other aspects of the business do not. I would think it rare to have different business entities within a corporation that have the same name.

I see you continue to move the goal post. We were discussing YOUR little example, not how often banks or other financial entities hail from the same address or have the same name.

My "little example" (as you put it) was EXACTLY THAT. A sample of how duplicate data can get past validations, and into a database, which was the original reason I created the example in the first place, way back in post #132:

In a large-scale system, data often comes from multiple sources. I am simply accounting for every possible scenario - both good and bad.

Nobody ever said that good planning and design aren't needed. However they are only a part of what is required. There is still a possibility of problem data coming in.

Here is an actual example:

Two different data entry people key in data for a stimulus recipient:

One keys: First Federal Savings and Loan - Amt Received 15 million - address 123 Main St., Suite 100 NY, NY 12345

Other keys: First Federal Svgs - Amt Received 10 million - address 123 Main St. #100, NY, NY 12345

Both pass program validations, and get entered into the database. The two entries generate two different recipient ID numbers (the primary key), and so they are treated as two separate companies.

YOU are the one who keeps changing the subject of the above to Database design, instead of simply talking about the possible conditions that can create the above scenario.

It's as if you don't want to admit that such a scenario can happen in the "real world". Well ... I hate to break it to you ... but in the world of Customer Databases, the above is very common.

Another example, is when you have two people who shop at the same store, live at the same address, and have the exact same name, but are actually two different people. I know you are asking ... how is that possible?

Well ... ever heard of a mother and daughter with the same first name ? Mary Smith and Mary Smith? Maybe they both share the same phone number (their home landline number). In this case, a birthdate may be needed to distinguish them.

Once again, a potential duplicate data issue.

You and I will never agree on this issue.

Apparently not.

[sanrene]

Did you notice the word tableS above? Pay particular attention to the "S" on the end of the word. It is there FOR A REASON. It means PLURAL. The data will not be stored in ONE TABLE ... as you seem to want to IMPLY.

I didn't imply that, you did with your example. I just corrected you.

You are the one who feels the need to discuss my "piece of paper" in database terms.

But that is what we were discussing, remember? You gave your example of how a DB can become polluted with "dirty data", I corrected you in proper design principles, you then gave another example that would still violate all the rules of normalization, so I gave you a simple recap of how the tables might look and how your assumptions and way of doing things would be responsible for a mess.

Do you always talk this way to experienced database developers ???

Uh, no. I'm not convinced I am, btw.

And just for the record...

Somehow, you have gone off on a hysterical tangent that has no bearing to the application being developed that is the topic of this thread. None of your scenario there would apply.

Customer ID is an internal number known only to the database system, and may appear on reports used by management and corporate employees. It is not known by customers or sales clerks in the stores. It is a meaningless sequentially assigned number that is used as a common key field to link customer tables together.

That is not necessarily true. In your example, which you have chosen to try and bolster your argument, is definitely NOT true in all cases. Depends on the application.

Even in your tables you listed, you have repeating data that opens up the possibility to problems. Technically, you wouldn't want to store

Sales Date
Store Number
Register Number
Transaction Number

in more than one table, which is what you are doing. You need one more table, maybe even 2, since merchandise(product) data should be in a separate table as well. Why repeat that data over and over again in each trans-det record? Hmmm...what normal form are you violating?

YOU are the one who keeps changing the subject of the above to Database design, instead of simply talking about the possible conditions that can create the above scenario.

Sorry, no. I pointed out your inherent flaw in the example you gave. You then expanded the criteria to include some malarkey about businesses that have different functioning entities but continue to keep the same name and address.

Another example, is when you have two people who shop at the same store, live at the same address, and have the exact same name, but are actually two different people. I know you are asking ... how is that possible?

Well ... ever heard of a mother and daughter with the same first name ? Mary Smith and Mary Smith? Maybe they both share the same phone number (their home landline number). In this case, a birthdate may be needed to distinguish them.

Once again, a potential duplicate data issue.

Now you're really reaching.

Customer ID is an internal number known only to the database system, and may appear on reports used by management and corporate employees. It is not known by customers or sales clerks in the stores. It is a meaningless sequentially assigned number that is used as a common key field to join customer tables together when needed.

It is true that a DB will assign an internal key to a unique identifier, which is what a randomly selected or user-defined custid primary key would be. But to call it meaningless is ridiculous.

Snuck in your SKU, I see. I was going to mention it. Oh well. And Quantity! How much more to make your little tables correct? Too late for that - your design is flawed - you have 2 less tables than you need.

Now, back to the actual topic. The wasting of $18 million to build from scratch a system that already exists.

[RD5050]

Originally Posted by sanrene

I didn't imply that, you did with your example. I just corrected you.

I implied NOTHING with my example.

All you corrected was your OWN ASSUMPTION, which was based on NOTHING that I ever said or implied.

But that is what we were discussing, remember? You gave your example of how a DB can become polluted with "dirty data", I corrected you in proper design principles, you then gave another example that would still violate all the rules of normalization, so I gave you a simple recap of how the tables might look and how your assumptions and way of doing things would be responsible for a mess.

Same scenario as above. You are correcting your own ASSUMPTIONS and nothing more.

It's like you are asking your own questions, and then answering them at the same time. I am not even involved in your conversation, since everything you talk about is based on meaningless assumptions about my method of database design, which I never even discussed to begin with.

I never even mentioned my method of database design until my previous post's Sales Transaction example.

Everything you've said about my previous posts is based purely on YOUR OWN ASSUMPTIONS ... and nothing more.

I wonder if that also how you work in real-life development? Maybe you just assume to know what the client wants, and then code it?

Uh, no. I'm not convinced I am, btw.

I won't even bother to comment. It's a waste of my time.

However, based on what I am able to detect about your experience with customer databases from this thread, I wouldn't employ your services.

Somehow, you have gone off on a hysterical tangent that has bearing to the application being developed that is the topic of this thread. None of your scenario there would apply.

Oh ...so when you make in incorrect assumption (sales clerk would enter customer id) ... and I correct YOUR MISTAKE ... it's suddenly an hysterical tangent?

That is not necessarily true. In your example, which you have chosen to try and bolster your argument, is definitely NOT true in all cases. Depends on the application.

There is absolutely no reason to use customer id in retail stores, at the time a clerk enters customer information. But unless you've had experience, you wouldn't know this.

Even in your tables you listed, you have repeating data that opens up the possibility to problems. Technically, you wouldn't want to store

Sales Date
Store Number
Register Number
Transaction Number

in more than one table, which is what you are doing. You need one more table, maybe even 2, since merchandise(product) data should be in a separate table as well. Why repeat that data over and over again in each trans-det record? Hmmm...what normal form are you violating?

You would if speed of data access in a large data warehouse requires it. Didn't you yourself state EXACTLY THAT in a previous post ??? Hmmm...
And surprisingly, you actually got that one correct. I guess there has to be a first time for everything!

I think I mentioned a while back that data warehouses allow a high degree of redundancy as a trade-off for speed and performance.

Sales transaction tables ABSOLUTELY have dept, class, style and sku. They are key fields used to join to Merchandise tables if needed.

Merchandise tables use these values as well, but they are used for a different purpose, for keeping track of quantity on hand, cost, etc. for buyers, and inventory needs.

Sorry, no. I pointed out your inherent flaw in the example you gave. You then expanded the criteria to include some malarkey about businesses that have different functioning entities but continue to keep the same name and address.

I didn't say ... the same name. I said ... similar names. Possibly differing by only the last word in the name.

Now you're really reaching.

Reaching ... by providing an actual real-life scenario, that is pretty common in customer data? This makes me believe you have very little or no "real world experience" with customer databases.

It is true that a DB will assign an internal key to a unique identifier, which is what a randomly selected custid primary key would be. But to call it meaningless is ridiculous.

CustomerID's are sequentially assigned. The last number used is maintained in it's own database, and that number plus one is assigned to new customers that enter the sytem. This number is only meaningful to corporate people, who may need to reference it for one reason or another. It is also used as a key to join customer tables when referencing a given customer.

It is totally meaningless to IN-STORE EMPLOYEES who work at POS terminals, since they never have a reason to know it.

[sanrene]

Same scenario as above. You are correcting your own ASSUMPTIONS and nothing more.

No. I'm responding to your posts, even though every time I do, you seem to expand and deflect - a perfect example is your retail POS example - how the heck did you devolve to that, which has no relevance to the issue? You began with an example (the long forgotten Bank with similar address and name) to try and prove your point, which I then pointed out how wrong you were, which then caused you to dig further by explaining a scenario to fit your argument.

I never even mentioned my method of database design until my previous post's Sales Transaction example.

Well, we were talking about poor DB design and planning relative to the issue of recovery.gov. When you listed your first example (how duplicate data might be entered into the DB), I noted that it would be incorrect to allow data to be entered as you had it, same with example two.

With your DB tables, I pointed out your errors in design.

If your primary function is working within a data warehouse environment, I can understand why you would make those errors, as we agree that DW demands a degree of redundancy in addition to how the data is stored.
In an operational environment there are different requirements and your example would not be ideal and would be considered poor design. Data integrity will take precedence.

However, based on what I am able to detect about your experience with customer databases from this thread, I wouldn't employ your services.

Ditto. I have come after work such as yours - it is never pretty and causes monumental headaches.

There is absolutely no reason to use customer id in retail stores, at the time a clerk enters customer information. But unless you've had experience, you wouldn't know this.

I know this. See above about the tangent. That is not where we started - you devolved down to the POS example to try and make your point.

You would if speed of data access in a large data warehouse requires it. Didn't you yourself state EXACTLY THAT in a previous post ??? Hmmm...

But we weren't really getting talking about that. You have talked about a few applications to try and make a point. That's what I mean about finding and example after the fact to fit your argument - your tables were not specified to be those in a DW environment - until after I pointed out where your logic was flawed. You did the same in the POS example.

Sales transaction tables ABSOLUTELY have dept, class, style and sku. They are key fields used to join to Merchandise tables if needed.

Merchandise tables use these values as well, but they are used for a different purpose, for keeping track of quantity on hand, cost, etc. for buyers, and inventory needs.

The ONLY value needed would be the SKU. The others are UNrelated to a Salestran. If you are talking about SEEING the dept, class,style on an invoice or screen - yeah, they would be retrieved from the Merchandise table for display - not to be stored over and over again in the Salestran table.

Merchandise would require it's own table.

Reaching ... by providing an actual real-life scenario, that is pretty common in customer data? This makes me believe you have very little or no "real world experience" with customer databases.

Coming across a mother and daughter with the exact same name, address, etc, etc is not a common practice - I guess it can happen. Since your first example of duplication didn't fly, I suppose you must drill down until you find something, anything.

CustomerID's are sequentially assigned. The last number used is maintained in it's own database, and that number plus one is assigned to new customers that enter the sytem. This number is only meaningful to corporate people, who may need to reference it for one reason or another. It is also used as a key to join customer tables when referencing a given customer.

It is totally meaningless to IN-STORE EMPLOYEES who work at POS terminals, since they never have a reason to know it.

In a POS, yes, it is not very relevant. As I stated before, that is not always the case. It depends on the application.

[RD5050]

Originally Posted by sanrene

No. I'm responding to your posts, even though every time I do, you seem to expand and deflect - a perfect example is your retail POS example - how the heck did you devolve to that, which has no relevance to the issue? You began with an example (the long forgotten Bank with similar address and name) to try and prove your point, which I then pointed out how wrong you were, which then caused you to dig further by explaining a scenario to fit your argument.

#1 - No ... you are reading what I say ... and then making assumptions of your own OUT OF THIN AIR.

Example ... my post:

Two different data entry people key in data for a stimulus recipient:

One keys: First Federal Savings and Loan - Amt Received 15 million - address 123 Main St., Suite 100 NY, NY 12345

Other keys: First Federal Svgs - Amt Received 10 million - address 123 Main St. #100, NY, NY 12345

Both pass program validations, and get entered into the database. The two entries generate two different recipient ID numbers (the primary key), and so they are treated as two separate companies.

And your response:

See, here's where your example goes down the crapper. In a properly design database, there is no way the tables would be structured as you have them. If that were allowed to happen, here comes your redundancies and duplicates.

Completely ... OUT OF THIN AIR ... you begin talking about DATABASE DESIGN ????

Nowhere in my above post do I indicate what the database structure will look like, or how many tables it will use when the data is loaded.

You simply decide ON YOUR OWN that I will be loading all the data into a single table?

All that I stated above is I will load several fields into a database. NOTHING MORE. Nothing about database design is mentioned. NOTHING AT ALL.

And then you follow up by INTENTIONALLY making INCORRECT ASSUMPTIONS about Database Design ... just so you can ACT as if I somehow need to have something corrected .... which I don't.

#2 - How did we arrive at a POS Transaction?

I gave you an example of a PIECE OF PAPER which has a name, address, and $ amount. (notice how these are the same 3 fields in the previous bank example?)

This PIECE OF PAPER can look any way you want it to look. You can put the $amt in the upper left-hand corner, the name/address on the back ... whatever you want.

And I tried to show you that the LAYOUT of this PIECE OF PAPER does not indicate ANYTHING AT ALL about Database Structure. And yet, somehow (who knows ... maybe by magic?) it is possible to key this data FROM THIS PIECE OF PAPER directly into a Database ??? WOW !!! A miracle !!! And somehow the $amount knows to go to one table (a sales-transaction table), the name address knows to go to another table (a customer table). Another miracle !!!

And since you were so keen on seeing database design, I voluntarily provided a sample layout of the above tables, to show you how they might be structured.

But the whole point of the above example was to show that it doesn't matter WHAT FORMAT the fields listed on the PIECE OF PAPER. There is NO REASON to be making ASSUMPTIONS about Database Design from a PIECE OF PAPER with a name/address and $amount scribbled on it.

Well, we were talking about poor DB design and planning relative to the issue of recovery.gov. When you listed your first example (how duplicate data might be entered into the DB), I noted that it would be incorrect to allow data to be entered as you had it, same with example two.

With your DB tables, I pointed out your errors in design.

There were NO ERRORS in my design. I DID NOT DESIGN ANYTHING for the first example. NOTHING AT ALL.

And the second example ... I showed a simple set of tables used for a basic POS Transaction.

And there was NOTHING wrong with these tables.

Even the data which you claim to be unneeded and redundant:

Even in your tables you listed, you have repeating data that opens up the possibility to problems. Technically, you wouldn't want to store

Sales Date
Store Number
Register Number
Transaction Number

in more than one table, which is what you are doing. You need one more table, maybe even 2, since merchandise(product) data should be in a separate table as well. Why repeat that data over and over again in each trans-det record? Hmmm...what normal form are you violating?

are part of the PRIMARY INDEX for both these transaction tables. They allow this INDEX to be unique.

If your primary function is working within a data warehouse environment, I can understand why you would make those errors, as we agree that DW demands a degree of redundancy in addition to how the data is stored.
In an operational environment there are different requirements and your example would not be ideal and would be considered poor design. Data integrity will take precedence.

Once again ... they are not errors. They are a PRIMARY INDEX.

I know this. See above about the tangent. That is not where we started - you devolved down to the POS example to try and make your point.

But we weren't really getting talking about that. You have talked about a few applications to try and make a point. That's what I mean about finding and example after the fact to fit your argument - your tables were not specified to be those in a DW environment - until after I pointed out where your logic was flawed. You did the same in the POS example.

Once again ... no flawed logic. Only flawed ASSUMPTIONS by you.

The ONLY value needed would be the SKU. The others are UNrelated to a Salestran. If you are talking about SEEING the dept, class,style on an invoice or screen - yeah, they would be retrieved from the Merchandise table for display - not to be stored over and over again in the Salestran table.

Merchandise would require it's own table.

SKU is not always present or valid (it can be a dummy sku), so it can't be relied on, so it is important to retain as much about the description of merchandise at the POS transaction level. But this is a business related issue ... not a database issue.

Coming across a mother and daughter with the exact same name, address, etc, etc is not a common practice - I guess it can happen. Since your first example of duplication didn't fly, I suppose you must drill down until you find something, anything.

Wrong. It is not uncommon for daughters to be named after their mother. And daughters shop at the same retail stores as their mother, and they often live with their mother until they are married or out of college. This is an issue which needs handling in a Customer Database.

Now that I have THOROUGHLY EXPLAINED the above ... I am still waiting for you to read the REQUIREMENTS DOCUMENT for recovery.gov version 2.0, and tell me exactly what is wrong with the project?

You seem to want to argue based on PURE SPECULATION (right-wing news articles, etc.).

Try reading the above document ... and then argue based on ACTUAL FACTS!!

[RD5050]

Also worth mentioning, is how you use "The Government" = "Obama" whenever it suits your needs, like the below thread:

https://www.city-data.com/forum/polit...ent-obama.html

Humor In The Workplace Seminars; Solicitation from the Government (obama)

however ... in this recovery.gov thread, you've spent an enormous amount of time arguing ... "The Government" = "The Taxpayers".

How convenient !!!