31–40 of 151 posts
I really like his indentation. I'm gonna use it. Most of it has been my style for a long time.
And then applies it for this query:
SELECT first_name AS fn
FROM staff AS s1
JOIN students AS s2
ON s2.mentor_id = s1.staff_num;
> If there is already a correlation with the same name then append a number. And then applies it for this query: SELECT first_name AS fn FROM staff AS s1 JOIN students AS s2 ON s2.mentor_id = s1.staff_num; I think that's terrible. s1 and s2 sound to me like they're instances of the same table that you had to JOIN with itself for some reason.
I have only done a little bit of work with SQL. Could someone please go into a bit more detail on a couple of these points for me? > Plurals—use the more natural collective term where possible instead. For example staff instead of employees or people instead of individuals. > Where possible avoid simply using id as the primary identifier for the table.
The second one is simply wrong because it burns brain cells when you come back to debug or extend something a year later and nobody memorizes the prikey of table production_quality_results, is it the serial number of the mfgrd object or the timestamp of the QAQC inspection or the serial number of the inspection activity or ... and when you look at column names in table 131 is drivers_license_id a foreign key to a row in the drivers_license table or just a raw store of data, like this is just where you store it in the system? This is especially hilarious if your FK and data source are similar bigint type, like a bigint to connect a FK to a prikey or is your component serial number literally a bigint itself, assuming the prikey is the data itself without dereferencing it will be a hilarious bug, "it seems serial number 10 doesn't exist in our assembly line" "Whoops thats actually row 10 of the production table, serial number whatevs".
Now we need a formatter/linter too
Though mostly good advice, I definitely disagree with this: DONT: Plurals—use the more natural collective term where possible instead. For example staff instead of employees or people instead of individuals. I like naming my tables as plurals so that foreign keys to the table rows can have a name that relates to the table name. For instance, having column `Orders.employee` as an FK to an `Employees` record makes much…
There are quite some languages that have different forms for the nominative, accussative, dative and genetive case. Lets take Latin and the concept of an unpaid developer (servus).
Servus is nominative singular. Lets make it plural: servi.
Select from servi...
select from servis...
update servos...
This might be a little overstretched.. Why don't we just use the normal form (the style guide talks about natural) of a noun? Good question, that is the singular nominative form. So, why make a special case for plural and ignore al other grammatical concerns?
Earlier quoted context omitted.
Not to mention with an ORM tool you'll have an Employee object, and probably call your collection employees. Which is better? foreach (var employee in staff) { } or foreach (var employee in employees) { }
> and probably call your collection employees. Really ? IMHO this is a bad practice : it makes the code les readable and breaks the auto-completion ...