Singular or Plural

  • Rod at work - Sunday, December 10, 2017 7:32 AM

    I 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
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • 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.

  • gbritton1 - Monday, December 11, 2017 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.

    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
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • Phil Parkin - Monday, December 11, 2017 7:42 AM

    gbritton1 - Monday, December 11, 2017 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.

    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.

  • gbritton1 - Monday, December 11, 2017 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.

    We definitely don't agree on what makes something readable. I would guess that context and the audience matters.

    412-977-3526 call/text

  • robert.sterbal 56890 - Monday, December 11, 2017 8:16 AM

    gbritton1 - Monday, December 11, 2017 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.

    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 ) )

  • Phil Parkin - Monday, December 11, 2017 7:42 AM

    gbritton1 - Monday, December 11, 2017 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.

    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.

  • robert.sterbal 56890 - Monday, December 11, 2017 8:16 AM

    gbritton1 - Monday, December 11, 2017 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.

    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.

  • Lynn Pettis - Monday, December 11, 2017 10:03 AM

    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 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
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • Lynn Pettis - Monday, December 11, 2017 10:03 AM

    Phil Parkin - Monday, December 11, 2017 7:42 AM

    gbritton1 - Monday, December 11, 2017 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.

    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

  • skeleton567 - Monday, December 11, 2017 8:25 AM

    robert.sterbal 56890 - Monday, December 11, 2017 8:16 AM

    gbritton1 - Monday, December 11, 2017 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.

    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.

  • 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.

  • RonKyle - Monday, December 11, 2017 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.

    I do as well.  It's important that one is consistent in how aliases are used for improved readability and team interaction.

  • 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

  • Eric M Russell - Monday, December 11, 2017 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.

    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
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

Viewing 15 posts - 46 through 60 (of 81 total)

You must be logged in to reply to this topic. Login to reply