|
Yes, but that doesn't answer my question.
|
|
|
|
|
Because not all projects have warehouses
Everything makes sense in someone's mind
|
|
|
|
|
Then the simplest solution is to have a "Not a warehouse" entry in the warehouse table. This technique works well if you present a (drop down) list of warehouses to the user who can then select the warehouse.
However, personally, I'd prefer, rather than having a warehouse Id column in the project table, having a (many-to-many) relationship table. Some projects would have an entry (just one), others would have no entry. This is likely a better design for your project*, but I suspect your project is too far along to do it this way.
* A warehouse has several projects, a project doesn't have a warehouse.
modified 18-Jan-12 19:58pm.
|
|
|
|
|
Why is having a 'no warehouse warehouse' better than allowing nulls in the table? A null is actually what best represents the situation the data's representing, and it makes the special case code a lot more obvious (comparing to null instead of comparing to a particular row key).
And adding a relationship table when it is a (nullable) many-to-one relationship seems like overkill, too.
|
|
|
|
|
BobJanova wrote: better than allowing nulls
It's just a way to avoid the special cases, and allows for addtional functionality, but it's really just a bandaid to cover up a flaw in the schema. I (probably) wouldn't do it that way.
BobJanova wrote: A null is actually what best represents the situation the data's representing,
Yes, but the schema doesn't seem to represent the real world.
BobJanova wrote: many-to-one relationship seems like overkill
Not to me. And from what I can tell, it better represents the real world. And, after reviewing the question again I see he already has two warehouses so he really should have many-to-many.
|
|
|
|
|
PIEBALDconsult wrote: It's just a way to avoid the special cases, and allows for addtional
functionality, but it's really just a bandaid to cover up a flaw in the schema.
I (probably) wouldn't do it that way.
You are claiming that a 'zero or one' type of association automatically insures a design flaw?
PIEBALDconsult wrote: es, but the schema doesn't seem to represent the real world.
What "real world"?
In my real world a specific inventoried item can either be non-existent (out of stock) or it exists in exactly one warehouse.
How do you keep one specific item in more than one warehouse?
|
|
|
|
|
jschell wrote: automatically insures a design flaw?
No, but it seems it is in this case.
jschell wrote: What "real world"?
I don't know, the post.
jschell wrote: in exactly one warehouse.
Yes, the item is in the warehouse, the warehouse is not in the item.
|
|
|
|
|
'X is in a Y' is usually represented by a Y column on table X, so a Warehouse column on table Item is what you'd expect in this case.
|
|
|
|
|
But, in my opinion, that's a poor design; it's better for 'X has a Y'.
The warehouse is not an attribute of the item, the item doesn't require a warehouse even if it is frequently in one.
BobJanova wrote: is usually represented by
Just because others are doing it, doesn't mean it's the correct way.
And it really seems like a bad idea for the particular code that was posted.
|
|
|
|
|
PIEBALDconsult wrote: The warehouse is not an attribute of the item, the item doesn't require a warehouse even if it is frequently in one.
To be clear in discussing the database schema....
That is design view.
The implementation, not design, can take one of two paths. And using one column is better in this case because it has less impact and because there is not possibility at all that the object can live in more than one warehouse.
Using a link table provides no functional benefit, provides no future benefit and will not make it any clearer to the next implementator what the relationship is.
If there was another different model, something besides inventory item and warehouse then a link table might be a better implementation choice.
|
|
|
|
|
jschell wrote: there is not possibility at all that the object can live in more than one
warehouse
Did you miss the part where the original code says "Warehouse2"? And this particular code refers to a "ProjectModel", not some item -- I don't know what the project is but it could be building an airplane, with some parts in one warehouse and others in another warehouse, and apparently some projects aren't in a warehouse at all.
jschell wrote: a link table provides no functional benefit
It would solve the poster's null-handling problem.
jschell wrote: provides no future benefit
It allows the "ProjectModel" to have any number of warehouses.
jschell wrote: If there was another different model, something besides inventory item and
warehouse
I'm pretty sure that's what the poster has.
And now for an anecdote: Many years ago I was helping maintain a system which had a table for holding customer accounts; some fields were used to hold a credit card number, type, and expiration date (not required). All well and good. Then a new client wanted their customers to be able to have two credit cards on file. I had to add copies of those same three fields, plus another to indicate which one was last used.  Then yet another new client wanted to allow their clients to have checking account information on file so they could do electronic transfers. More stinking fields were added to the table.
The system would have been much easier to maintain had the original developers made a separate table to hold information related to this sort of thing.
You should always allow for maximum flexibility because you do not know what the future holds, and Murphy is just around the corner.
I believe this portion of this article http://en.wikipedia.org/wiki/Database_normalization[^] is appropriate:
"
Minimize redesign when extending the database structure
When a fully normalized database structure is extended to allow it to accommodate new types of data, the pre-existing aspects of the database structure can remain largely or entirely unchanged. As a result, applications interacting with the database are minimally affected.
"
|
|
|
|
|
PIEBALDconsult wrote: You should always allow for maximum flexibility because you do not
know what the future holds, and
I agree that neither I nor anyone else knows what the future holds.
Your view requires that the entire enterprise system must be over engineered based on the expectation that out of every 100 "flexible" design/implementation choices that one will be used.
That ignores the cost of implementing the other 99 in the first place and maintaining them for years.
PIEBALDconsult wrote: hen a fully normalized database structure is extended
No one in their right mind "fully" normalizes a database, so that statement is obviously false from the start (think 5th normal form.)
|
|
|
|
|
BobJanova wrote:
Why is having a 'no warehouse warehouse' better
than allowing nulls in the table? A null is actually what best represents the
situation the data's representing, and it makes the special case code a lot more
obvious (comparing to null instead of comparing to a particular row
key).
And adding a relationship table when it is a (nullable)
many-to-one relationship seems like overkill, too.
All of that seems exactly correct to me as well.
|
|
|
|
|
If there is too much downstream code already written that reference Warehouse1 and Warehouse2, then I like your approach. If you can, then downstream code should be able to handle Warehouse1 and Warehouse2 being nulls within the ProjectModel in which case you could just return null from getWarehouseModel or wrap the call with
p.WarehouseId1 == null ? null : getWarehouseModel( p.WarehouseId1.Value )
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
|
Could you evaluate WarehouseId1 in the getWarehouseModel method instead. It sounds like the logic would be better placed there
"You get that on the big jobs."
|
|
|
|
|
I can see three ways:
1. Do what you have now.
2. Have the separate relation table PIEBALD suggested.
3. Have a special warehouse, a real entry in the database, however it corresponds to "no warehouse" with values (stock, staff count, ...) that match that (probably just all zero, and a dummy address).
|
|
|
|
|
If you are strictly modelling what's in the database, then I would simplify this by making it so that Warehouse1 and Warehouse2 were nullable, and I would let getWarehouseModel return null if the warehouse id was null. Also, are you sure that your logic for getWarehouseModel is correct with regards to what you are evaluating? You seem to be using WarehouseId1 in both cases and it seems redundant evaluating it twice.
|
|
|
|
|
hi
i should create a data base by c# that save employee imformashion and save their salary list. . . ????
|
|
|
|
|
Before you can actually progress with this project, you really need to flesh out your requirements. What employee information do you need? Do you require security in place? How are you going to present this to the user? Is it browser based? Is it Silverlight, Windows Forms, WPF? Do you need to audit changes?
As you can see, there's a lot that you need to do before you go any further.
|
|
|
|
|
tnx a lot for your explanation i khow but it's my homework  and i have not enough time 
|
|
|
|
|
fafal wrote: i have not enough time
So, how did you assume others here have enough time to do "your" homework.
|
|
|
|
|
 yeah your righ  but i never think like you when someone need help , and i dont khow why here all are furious tnx anyway
|
|
|
|
|
Because we do not do homework for you.
And of course, we are ready to help you if you have tried something on your own and come here with specific questions. But that doesn't seem to be the case.
|
|
|
|
|
ok give in 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
