December 10, 2017 at 7:43 am
Rod at work - Sunday, December 10, 2017 7:32 AMI haven't heard anything about the end of life of EF. Really?
While I have no idea as to the validity of the statement, I can see from the English that this is not about EF, but about EF Designer, whatever that is.
All the same, the designer has an end of life in view since no further renditions of EF will support it
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
December 11, 2017 at 7:27 am
Consider this query:
SELECT id, name, email
FROM Customers
Now, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customer
So now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
December 11, 2017 at 7:42 am
gbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
Interesting. When I see a mass of column names preceded by long alias names, my brain fogs and I just want to reduce the clutter.
I'd alias 'Customers' as 'c' in the above.
I also think that two-part names should be optional, if only one table is mentioned in the FROM clause.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
December 11, 2017 at 7:52 am
Phil Parkin - Monday, December 11, 2017 7:42 AMgbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
Interesting. When I see a mass of column names preceded by long alias names, my brain fogs and I just want to reduce the clutter.
I'd alias 'Customers' as 'c' in the above.
I also think that two-part names should be optional, if only one table is mentioned in the FROM clause.
I pretty much require two-part names in the code reviews I do. It saves ambiguity later when the query gets changed to join to other tables. (And they do get changed!) Don't disagree about short aliases, though that's not my point, which is that I'm less concerned with the actual table name and more interested in an appropriate (and singular) alias.
December 11, 2017 at 8:16 am
gbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
We definitely don't agree on what makes something readable. I would guess that context and the audience matters.
412-977-3526 call/text
December 11, 2017 at 8:25 am
robert.sterbal 56890 - Monday, December 11, 2017 8:16 AMgbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
We definitely don't agree on what makes something readable. I would guess that context and the audience matters.
OK, guys. This has reached the point of being ridiculous. Now we have an alias that is the singular of its own plural? So now I have to go to the trouble of remembering which is which. I think this is splitting hairs over something for no benefit. And I will NOT abbreviate IN MY HUMBLE OPINION. 🙂
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 11, 2017 at 10:03 am
Phil Parkin - Monday, December 11, 2017 7:42 AMgbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
Interesting. When I see a mass of column names preceded by long alias names, my brain fogs and I just want to reduce the clutter.
I'd alias 'Customers' as 'c' in the above.
I also think that two-part names should be optional, if only one table is mentioned in the FROM clause.
I still use two part names, habit. Plus, what happens when the one table query becomes a multi-table query? I'd rather have the aliases already in place.
December 11, 2017 at 10:07 am
robert.sterbal 56890 - Monday, December 11, 2017 8:16 AMgbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
We definitely don't agree on what makes something readable. I would guess that context and the audience matters.
Aliases should be short but representative of the table is some manor. For instance, I will use ospr as the alias for the table OperationsSIGACTPublishedReport.
December 11, 2017 at 10:18 am
Lynn Pettis - Monday, December 11, 2017 10:03 AMI still use two part names, habit. Plus, what happens when the one table query becomes a multi-table query? I'd rather have the aliases already in place.
I do too.
But SQL Prompt fills them in automatically, if required, when moving from 1 table to 2 or more, so it's no extra effort.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
December 11, 2017 at 10:24 am
Lynn Pettis - Monday, December 11, 2017 10:03 AMPhil Parkin - Monday, December 11, 2017 7:42 AMgbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
Interesting. When I see a mass of column names preceded by long alias names, my brain fogs and I just want to reduce the clutter.
I'd alias 'Customers' as 'c' in the above.
I also think that two-part names should be optional, if only one table is mentioned in the FROM clause.I still use two part names, habit. Plus, what happens when the one table query becomes a multi-table query? I'd rather have the aliases already in place.
I also use two part names, but one of the tools that I'm using (Aqua Data Studio) is set up to remove the table name/alias if the column name is unique. :crazy: I haven't figured out how to disable that bug.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
December 11, 2017 at 10:44 am
skeleton567 - Monday, December 11, 2017 8:25 AMrobert.sterbal 56890 - Monday, December 11, 2017 8:16 AMgbritton1 - Monday, December 11, 2017 7:27 AMConsider this query:
SELECT id, name, email
FROM CustomersNow, we all know that we should use aliases and two-part names, so version two might be:
SELECT customer.id, customer.name, customer.email
WHERE customer.name = 'Arthur Dent'
FROM Customers AS customerSo now, I have a table with a plural name, but I use a singular alias since in the SELECT, I'm really only talking about one row at a time. For me that's what's important -- the alias that is. The actual table name doesn't concern me so much. What I want is readability of the whole query.
We definitely don't agree on what makes something readable. I would guess that context and the audience matters.
OK, guys. This has reached the point of being ridiculous. Now we have an alias that is the singular of its own plural? So now I have to go to the trouble of remembering which is which. I think this is splitting hairs over something for no benefit. And I will NOT abbreviate IN MY HUMBLE OPINION. 🙂
(Forest! Meet trees!!)
So how about transforming:
SELECT id, name, email
FROM VeryImportantEnterpriseBigBucksCustomers
to
SELECT cust.id, cust.name, cust.email
FROM VeryImportantEnterpriseBigBucksCustomers AS cust
The point is to have the query in singular form as far as possible, whatever the form or length of the real table or view name.
Choose your own table name, plural or singular, long or short. Use an alias that is singular. One character can be nice, though I find that can be confusing in a complex queries with lots of joins and/or sub queries. YMMV.
Also...adopt the habit of always aliasing tables/view in queries, even simple ones. You'll thank yourself later.
December 11, 2017 at 11:11 am
Aliases should be short but representative of the table is some manor. For instance, I will use ospr as the alias for the table OperationsSIGACTPublishedReport.
I do it this way as well. I don't think I've yet run into a conflict between table abbreviating to the same combination that needed to be in a query together.
December 11, 2017 at 11:22 am
RonKyle - Monday, December 11, 2017 11:11 AMAliases should be short but representative of the table is some manor. For instance, I will use ospr as the alias for the table OperationsSIGACTPublishedReport.
I do it this way as well. I don't think I've yet run into a conflict between table abbreviating to the same combination that needed to be in a query together.
I do as well. It's important that one is consistent in how aliases are used for improved readability and team interaction.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
December 11, 2017 at 11:57 am
When I'm wearing the DBA hat, I really don't comment much at all regarding the application developer's choice of naming convention, because ultimately they are the one's who have to code against it. I'd rather focus on normalization and optimization.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 11, 2017 at 12:11 pm
Eric M Russell - Monday, December 11, 2017 11:57 AMWhen I'm wearing the DBA hat, I really don't comment much at all regarding the application developer's choice of naming convention, because ultimately they are the one's who have to code against it. I'd rather focus on normalization and optimization.
You are, however, the one who gets to look at execution plans, traces, logs and all sorts of other SQL Server paraphernalia, none of which have aliasing!
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 15 posts - 46 through 60 (of 81 total)
You must be logged in to reply to this topic. Login to reply