![]() | |
#61
| |||
| |||
|
|
Funny, even you can't design properly in your data model. |
#62
| |||
| |||
|
|
The original question was about a *normalized* many-to-many design. Your solution uses a completely different design that's not even 1NF. |
|
Why do you rattle on about normalization when your product doesn't support it and you don't use it? |
#63
| |||
| |||
|
|
BTW, your design also mixes meta data and user data. Using user data values as names (meta data) is incorrect. |
#64
| |||
| |||
|
|
* The Ultimate DBMS is here! |
#65
| |||
| |||
|
|
Yes, and the string 'Troy' is a fact as much as a quarterback or a city is a fact. |
#66
| |||
| |||
|
|
Anyway, I'm done here. |
|
You continue to blur important distinctions. Your only purpose in claiming that values and facts are the same is to confuse and to prevent meaningful discussion. |
#67
| |||
| |||
|
|
You continue to blur important distinctions. Your only purpose in claiming that values and facts are the same is to confuse and to prevent meaningful discussion. Feel free to call somethings "facts" and others "values" within the context of RM. |
#68
| |||
| |||
|
|
(Bite my tongue for responding to you! But...) You are indulging in gross distortions. This is bigger than RM or even database. These concepts apply to logic, mathematics, language, ... A fact is a logical proposition that is true or not. Try saying this out loud: Sam has 2 children is true. This makes sense. 1492 is true or 'Troy' is true makes no sense, without additional context to turn it into a proposition or fact. I'm just tired of your crap. You refuse to educate yourself. |
![]() |
| Thread Tools | |
| Display Modes | |
| |