Primary Key WTF
-
@asuffield said:
@ShadowWolf said:
@asuffield said:
@aib said:
Definitely agree on the declaration syntax, why would I want to read the type from the variable name outwards? (Though there might be a technical explanation for that, which I dare not waste time guessing atm)
It's historical. There's no particular reason why it has to be that way around, but the previous one was, and it was copied. Offhand I can't recall which language originated this slightly bizarre syntax.
I believe you're thinking of B, which was just completely wonky.
B inherits directly from BCPL and Bon, BCPL inherits from CPL, which inherits from ALGOL. Somewhere along the line, this syntax appeared. I'm not sure where.
Perhaps it might have come from ALGOL, but I'm pretty sure that B's array syntax was an evolution of the way it was declared in BCPL, which still used a slightly different syntax for array declaration.
But there could have been some kind of evolution point for BCPL that I do not know of. I was not even alive when BCPL was in common use :)
-
@Obfuscator said:
For me personally, using id as a pk is primarily for those 'Why can't I change my username?' questions which arise sooner or later.
Not only that. It's also a bit about reusability. Imagine you are a company that creates software for webshops. Obviously, this software has to interface with ERP software (SAP, Navision etc.) and as it goes, their key structure has to become yours. Of course you could try to hide it in the interfaces and have your own definitions, but imagine the poor employes that have to deal with both systems.
So, one ERP system identifies an order by business_unit_code+year+ordernumber; another ERP system by clientcode+ordernumber. Whatever. The same goes for the primary keys for products, customers, etc. You have to adopt your system to reflect the way the ERP system thinks, since SAP will not adopt your ideas. Probably. If your system is well designed, it's not difficult to adopt the user interface to handle that. But for the data model, life is much easier if you have an (to the user) invisible ID that is used for all the relations between orders, clients, products etc. A lot of business logic can be reused unchanged if the external key structure is not the same used for references within the database. This is especially true when your business language is written in stored procedures, so there is no data abstraction layer that can partially hide those dirty details.
-
@aib said:
Definitely agree on the declaration syntax, why would I want to read the type from the variable name outwards? (Though there might be a technical explanation for that, which I dare not waste time guessing atm)
That's actually logical:
int i, *p, a[70];means that i holds an integer value, *p (the memory location that p points to) holds an integer value, and a[0] through a[69] hold integer values.
-
@dasluq said:
That's actually logical:
int i, *p, a[70];means that i holds an integer value, *p (the memory location that p points to) holds an integer value, and a[0] through a[69] hold integer values.
Actually, C programmers have learned to understand it, but that doesn't make it logical.
IMHO, there are two styles of variable defintion that deserve the predicate "logical":
name type
and
type name.
Unfortunately, "int a[70]" does not match either style. The "70" to indicate a range of 0..69 is also ugly.
The following definitions could be considered logical
a int[0..69]
int[0..69] a
-
@ammoQ said:
@dasluq said:
That's actually logical:
int i, *p, a[70];means that i holds an integer value, *p (the memory location that p points to) holds an integer value, and a[0] through a[69] hold integer values.
Actually, C programmers have learned to understand it, but that doesn't make it logical.
IMHO, there are two styles of variable defintion that deserve the predicate "logical":
name type
and
type name.
Unfortunately, "int a[70]" does not match either style. The "70" to indicate a range of 0..69 is also ugly.
The following definitions could be considered logical
a int[0..69]
int[0..69] a
I kinda prefer the syntax int[70] a; like you see in C#.
I would rather my declaration quickly tell me how many elements I have requested, not necessary the way in which those elements are indexed. Also, it begs the question whether it's logical to write int[4..327] a; which makes no real sense. When you later see a[4] you're going to think it's the 4th or 5th element more than you'll think it's the 1st.
I do not like int a[70] although I understand the logic.
I believe Mr. Stroustrup has said that C declarations were written in the way they were designed to be read: 70 elements of type int. Similar to how you'd read a pointer in C, int* a - a pointer to an integer. But that's 100% from memory and it's been a while since I've read much of his C++ book. I know he tried to fix some of that in C++, but people complained and didn't care for it.
-
In addition to replication it is occasionally very good to know what key was inserted before the others but theres no need for full time stamping.The only case in a data structure when a table wont need a primary key according to my logic is when that table represents a n:n relation.
-
@ShadowWolf said:
I would rather my declaration quickly tell me how many elements I have requested, not necessary the way in which those elements are indexed. Also, it begs the question whether it's logical to write int[4..327] a; which makes no real sense. When you later see a[4] you're going to think it's the 4th or 5th element more than you'll think it's the 1st.
At least the choice between [0..11] and [1..12] would make a lot of sense in many cases. (Of course only for arrays that are not abused as strings)
You might also sometimes want an array with ranges like [128.255] to map the non-ASCII characters of a character set to their unicode number.
Many programming languages allow for such arrays. C doesn't, but C lacks almost everything that can be kinda replaced by other language features.
-
@ShadowWolf said:
I believe Mr. Stroustrup has said that C declarations were written in the way they were designed to be read: 70 elements of type int. Similar to how you'd read a pointer in C, int* a - a pointer to an integer. But that's 100% from memory and it's been a while since I've read much of his C++ book. I know he tried to fix some of that in C++, but people complained and didn't care for it.
Now that I've come to think of it, reading types from the inside out might be the easy way.
...but not necessarily intuitive. Of course, C might want to consider changing RTL associativity of the [] type modifier before doing anything else about readability. (And whoever uses a declaration such as above should be shot.)
@ammoQ said:
Many programming languages allow for such
arrays. C doesn't, but C lacks almost everything that can be kinda
replaced by other language features.That's what I like about it. The ternary operator is possibly the most complex element of the language.
Maps to assembly and back quite nicely, in my head.
-
I fail to see what the problem is - looks like ol' "TubeRodent" is claiming anything he doesn't agree with as a WTF. There's nothing wrong with using "ID" as a primary key. In fact, the greatest web framework ever, Ruby on Rails (that's said jokingly, by the way, although I do like RoR) expects you to do it or you have to do some additional configuration (convention over configuration, after all).
