Are you disagreeing with me? I can't tell.

Post #108,100 by tseliot 7/1/03 4:18:35 PM Reply	Are you disagreeing with me? I can't tell. ALL tables need PK's...Unless you want your sp's to update all "non-atomistically distinct" detail rows in your detail table. Is that not what I said? Or was it the extra step that happened to notice: a sentence written "all...unless" is pretty much the same as saying "not all"? As far as stored procedures go...wait, let me count them in my code...I count nearly... nearly one. Yes, I think that's right--nearly one. Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #108,339 by mmoffitt 7/3/03 11:23:33 AM Reply	Dunno if I disagree. You write (in part) wrt Primary Keys: ??? First of all, I think you mean "design of a table (or perhaps 'these two tables')", and second, that's not true for all tables. I know the topic is not a real database, but the idea that there exists a database table that does not need a primary key is foreign to me. If that is your view, then I am most definitely in disagreement with you. If you've never worked with a real database, and you don't know that in most secure databases users are prevented from accessing tables directly and can only access the data in the tables through stored procedures and views (and you definitely want insert/update/delete sp's - and yes that's stored procedure), then it's not surprising that you hold that primary keys are unnecessary on some tables. But, you're absolutely wrong if that is your view. Even with toy databases you should put a PK on each table. Doing so can save yourself grief should your little app ever need to scale up. Not doing so is a violation of "good design". bcnu, Mikem "Son, if you haven't got time to do it right the first time, where are you going to find the time to do it a second time?" - Dewey Keller, my grandfather
Post #108,362 by tseliot 7/3/03 2:10:46 PM Reply	Toy and scale are not the issues. Design is the only issue I'm talking about. Not every table has unique elements, because not every Set of objects in the real world has unique elements. Example: you have 30 tool packages you can rent out to customers, all the same. There is no distinction between them. There never will be a distinction between them. That is the whole point: they are the same in every way. A table which models these 30 tool packages does not need a primary key. You might feel safer with one, but that does not erase the fact that there is no need for one. All that matters is that we do not oversell them. A primary key does not assist in this process at all. Would it hurt to have one? Probably not. If you want the overhead, be my guest. I can just see kindergarten class: "Now if Jimmy has five apples, and we take away 3 apples.." "Ooh, ooh, wait! Which three are we taking away?" "It doesn't matter, just subtract three." "But which three?" "It doesn't matter!" "Oh, it most certainly does. Why don't these apples have barcodes so we can tell them apart? Billy, go get the label maker! Susie, find us a workbench and clamp! Margaret, you start cutting the crystal for the laser...we need a reader..." Overkill. Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #108,369 by CRConrad 7/3/03 3:51:15 PM Reply	Then you don't need a thirty-line table at all... ...but a numeric variable `NumberOfToolSetsRented` somewhere, that fluctuates between zero and thirty. Worst case, you have to have a (one-line) table to keep it in. Then you can just update that table (increase or decrease the value by one) every time a toolset gets rented out or returned... And the way to do that is, of course, by using a stored procedure. Oh, and if you ever find you only have twentynine toolsets on hand, and want to know which customer didn't actually return his as he was supposed to, then what do you do? Then you wish you'd bar-coded your toolchests and used the `ToolChestID` value of the barcode as a primary key, that's what do you do. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #108,404 by mmoffitt 7/3/03 10:56:12 PM Reply	Thank you. bcnu, Mikem The soul and substance of what customarily ranks as patriotism is moral cowardice and always has been...We have thrown away the most valuable asset we had-- the individual's right to oppose both flag and country when he (just he, by himself) believed them to be in the wrong. We have thrown it away; and with it all that was really respectable about that grotesque and laughable word, Patriotism. - Mark Twain, "Monarchical and Republican Patriotism"
Post #108,435 by FuManChu 7/4/03 1:18:46 PM Reply	Should I answer? This is becoming religious and I don't see anyone convincing anyone else. You've all got your methods; use them. I have an extra tool that I can use with or without your blessing. So I'm not going to beat this example to death; it was a bad example from the beginning because it only gains significance if scaled up, which was part of the issue I was trying to avoid. If you can't generalize the concept from the example, then again we go nowhere, and the gain frankly isn't worth it even if one of us happened to convince another. The only point I WILL make at this juncture, is this: Then you don't need a thirty-line table at all...but a numeric variable `NumberOfToolSetsRented` somewhere, that fluctuates between zero and thirty. Um... get thee behind me? This is, IMO, a far WORSE solution, since you are now hard-coding minute details of the transaction INTO A FREAKING VARIABLE NAME. What was that about scaling up? I give it...six months before such a horrible hack would get taken back out of the code. Make an invoice object with a `Qty` property, maybe, but `NumberOfToolSetsRented` is going too far. I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
Post #108,395 by a6l6e6x 7/3/03 9:56:56 PM Reply	But, but, a tool of any value has a serial number and they.. are different. Warrantees or support, if any, are tracked by serial number by the manufacturer. Suppose, on return, your clients substituted a barely functioning tool of the same model for one they rented. How would you know? Are we talking hammers here? :) Alex The tendency to turn human judgements into divine commands makes religion one of the most dangerous forces in the world. -- Georgia Harkness in "Conflicts in Religious Thought" (1929)
Post #108,436 by FuManChu 7/4/03 1:24:29 PM Reply	In this particular case Suppose, on return, your clients substituted a barely functioning tool of the same model for one they rented. How would you know? Are we talking hammers here? :) We are talking hammers, at my company. So "barely functioning" is no different than "functioning". Components of the toolkits (like hammers, shovels, etc.) get damaged and lost all the time, and that gets noticed and dealt with by humans at the time of restock. The cost of numbering would far exceed any benefit, since the toolkits often get moved from site to site "on the fly", without time to come back to base camp. I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!

Welcome to IWETHEY!