141–150 of 151 posts
Earlier quoted context omitted.
Which is fine if you are aware of the differences between the two. Since they act differently.
I don't think so, what differences are there? Could this be a database specific thing? In PG it seems equivalent.
Earlier quoted context omitted.
Thinking multi-column indexes here.
Yes, but it's in the 'Constraints and keys' section. It even says 'Constraints, and their subset, keys'. As far as I'm aware, an index is not a constraint, except for a unique index, which implies a unique constraint. Having said that, I can't think of an explanation more likely than yours.
An illustration in bad pseudocode:
PRIMARY KEY (account_number, transaction_date)Earlier quoted context omitted.
Yes, but it's in the 'Constraints and keys' section. It even says 'Constraints, and their subset, keys'. As far as I'm aware, an index is not a constraint, except for a unique index, which implies a unique constraint. Having said that, I can't think of an explanation more likely than yours.
Well that's good seeing as though I wrote the guide in the first place. An illustration in bad pseudocode: PRIMARY KEY (account_number, transaction_date)
Apologies, I didn't realise. That was crass of me.
But could you explain what you mean by unique in some degree? Surely in the example you give the key is just unique, with no further qualification?
Earlier quoted context omitted.
The debate about singular/plural naming for relations comes up frequently. In my opinion, it stems from the fact that English has only 2 forms for all the possible grammatical cases. It has only a different form for the singular and plural cases, and thats what people concentrate on. I propose to take a step back. There are quite some languages that have different forms for the nominative, accussative, dative and gen…
It makes me curious if you apply the same rule to variable names in (other) programming, when they contain multiple items of a kind (e.g. arrays, lists, sets and so on). FrequentCustomerArray rather than FrequentCustomers ? If not, why is that different?
map(foo, FrequentCustomers)
foo(FrequentCustomer[0])
map foo($_), @FrequentCustomer;
foo($FrequentCustomer[0]);Earlier quoted context omitted.
Yes, though generally only if a field or table name happens to be a SQL keyword.
In SQL server? In PostgreSQL you would wrap with double quotes. Which kinda sucks when your language uses double quotes for strings and you have to escape.
Earlier quoted context omitted.
> S for staff and ST for students This isn't memorable: staff and students both start with st!
I'm aware of that. However, it only has to be memorable for the period of time you're working with a query. If you open up an old view or stored procedure to modify it, you would read the table aliases first. If someone wasn't able to retain the meaning of 'S' and 'ST' for the length of time needed to modify a query then perhaps working with code isn't for them. Lastly, if someone did have poor memory they could leng…
Better :) But I prefer to just give my tables short names to begin with. How about staff and pupils? That's so short that there is little temptation to abbreviate.
I have often seen commas placed at the start of each line when columns are being listed. I'm a little surprised this guide doesn't follow that convention. It would fit nicely with the established pattern of lining everything up: SELECT first_name , last_name , email_address FROM users Can anyone speculate why it's not done this way in the guide? I think the reasoning behind it was to make later modification easier be…
Weird, I really dislike a lot of the suggestions. In particular, an example: SELECT first_name AS fn FROM staff AS s1 JOIN students AS s2 ON s2.mentor_id = s1.staff_num; We already agreed that staff is a good name for a table, so why are we renaming it to s1? There are all sorts of subtle bugs that arise when s2.mentor_id = s1.staff_num is wrong, and the variable names provide no help here that we're doing things rig…
> Honestly, I think AS should basically never be used for tables. I believe AS is required for self-joins. A common expository query is to find all employees who earn more than their managers, which can be expressed via "select name from staff as employee join staff as manager on (employee.manager_id = manager.id) where employee.salary > manager.salary". Also, SQL allows a sub-select to be listed in the FROM clause.…
Earlier quoted context omitted.
Well that's good seeing as though I wrote the guide in the first place. An illustration in bad pseudocode: PRIMARY KEY (account_number, transaction_date)
> Well that's good seeing as though I wrote the guide in the first place. Apologies, I didn't realise. That was crass of me. But could you explain what you mean by unique in some degree? Surely in the example you give the key is just unique, with no further qualification?
What I meant is that if you don't have a unique column to make, say, a primary key with then you need to make it unique by adding (an)other column(s) to it in the key definition. Each additional column being a degree of difference/separation in my mind as I was writing it.
I hope that explanation makes sense and doesn't confuse the issue further.
I'd like to get your feedback on what you think it could say to make this clearer - I want to convey:
a. it must be unique.
b. you can have multi-column keys (some users - especially those tied to an ORM - don't actually know that you can do this).
Glad to see I conform to the guide in most places, but one thing I have been doing for nearly all 35 years of my programming career is to prefix my SQL views with `vw` so that I can tell immediately in my queries when I am referencing a view that may be made up of other queries.