Naming Queries

At first, when at the level of UnconsciousIncompetence, it seems like something easy, I will name that query: "GetAllEmployees", and that other "GetAllCountries", and that one will be "GetAllIceCreamFlavors" but then, they ask you to get all employees that are women, so you write GetWomenEmployees, but then they ask you to get only those that are older than 30 years, and then you write GetWomenEmployeesOlderThan, but then, they ask you to remove some of the fields in the Employees table (for example they do not want to know the exact age so they do not want it in the resulting table), so you write GetWomenEmployeesWithoutAgeAndOlderThan (that starts to be a confusing name, doesn't it?), and then they want you to join LastName and FirstName in a single column, and hide the "Sex" column, but, please, do that in another method/stored proc/view/function because the current one we are already using it for some joins and we need those columns... so you keep the current method/stored proc/view/function and write another one named GetWomenEmployeesWithFullNameWithoutAgeWithoutSexAndOlderThan... or maybe GetEmployeesWithSexFemaleWithoutAgeWithoutSexWithFullNameAndOlderThan or perhaps GetEmployeesOlderThanWithSexFemaleWithoutAgeWithoutSexWithFullNameAnd or any other possible permutation... or perhaps, if you are a very lazy developer, that does not care about using MeaningfulNames, you only have GetEmployees3...

By this point, you only need a few more request of customization of the query (like lets say a join with 2 or 3 tables) to start having a name that is so huge that is is more cumbersome than writing the actual query.... or plain giving up and start using meaningless names for your queries...

What is the solution?

Don't try to name queries by their content but by their intended purpose or role, the same way you'd name procedures or methods.

You answer strikes me as simplistic, after all the purpose for GetWomenEmployeesWithFullNameWithoutAgeWithoutSexAndOlderThan is to get a list of women, who are employees, with their full name in a field, without age column, without sex column and older than a particular date so... I am already doing what you say, and it does not help...

Is that really the query's purpose? Or is it actually (say) GetMatureFemalesForAnnualMarketingSurvey? Or even GetMatureFemaleEmployees?

Well, what if I need the MatureFemalesForAnnualMarketing, but to satisfy use case A and B I need columns X,Y,Z ordered by Q,R,T, and for use case P and Q I need columns Y,U,Z ordered by T,R,F and for use cases... see the naming nightmare now? I certainly can not call all of those queries GetMatureFemaleEmployees unless I do not care about distinguishing them.

I'd probably call one GetMatureFemaleEmployeesForAnnualMarketing and the other GetMatureFemaleEmployeesForSalesReport, or whatever.

Or tell, me, what name could I use, that would also help me to distinguish it from the case where I need to get a list of men, who are retired, with their name and last name in separated fields, with age column, without sex column and younger than a particular date?

If what you need is a generic report generator, perhaps you should consider purchasing/writing one?

I might need this queries to satisfy, lets say, 5 different use cases each, under 5 different contexts, that just that happen to reuse this queries... what do I do then? create a copy of the query for each context? why wrap it under a name then? I could of course just rename it as GetDataForDisplay but then I would getGetDataForDisplay1, GetDataForDisplay2, GetDataForDisplay3, which would be pretty meaningless, don't you agree?

and what about reuse? say I call my query: GetDataForUseCaseWhatEver, and then I need to reuse that query, by joining its result with GetDataForUseCaseWhatnot, would that be a good example of good readability? (note that this also forces me structure my queries around use cases... or something like them) or would the developer looking at the join between GetDataForUseCaseWhatEver and GetDataForUseCaseWhatnot would find it pretty hard to understand what is the purpose of the combination without a deep understanding of those use cases? (of course with a query language as crappy as SQL it might be impossible to do this kind of reutilization, but lets assume that we are using some future querying language that does allow this kind of thing.)

Maybe the standard for naming queries should be something like GetDataForProcessSomethingAtUsecaseSomethingElse? (note that then the names of the involved tables are not part of the query name, making it harder to grasp what the query is going to return... and if to understand that I need to look at the code then, why wrap it behind a name?)

How do you deal with this issue when naming procedures, functions, operators or methods? After all, a query can be considered conceptually equivalent to an operator that returns a set of rows.

{I'm of the opinion that long names are an indication that something should be broken into smaller parts. Can GetWomenEmployeesWithFullNameWithoutAgeWithoutSexAndOlderThan be refactored into smaller parts? Perhaps each filter could be split into its own method and each with/without part could be it's own method. If the methods all belong to some Query object, then they can operate on it and return it so you can chain calls. If that's possible, it could be called like AllEmployees().WhereWomen().WhereOlderThan(30).WithFullName().WithoutAge().WithoutSex().Get().}

Indeed, there are query-construction toolkits that work in precisely this manner, and they often work well. However, that doesn't address what name to give the result of using the query builder. If the query doesn't require a name -- e.g., the builder can be invoked whenever a query is needed -- then it's immaterial how the query gets built. I assume the original poster has an implicit requirement that a query -- defined via whatever means -- must be given a static name.

You have not solved the problem, you are just giving up on naming and plain writing the query, whenever you need all list of women, who are employees, with their full name in a field, without age column, without sex column and older than a particular date you are writing all that: AllEmployees().WhereWomen().WhereOlderThan(30).WithFullName().WithoutAge().WithoutSex().Get(). The difference between that an copy&pasting the query in SQL, TutorialDee or HSQL?: None.

Again: Conceptually, a named query is a user-defined operator that returns a set of rows. How do you come up with suitable names for any shared or re-usable user-defined operator/function/procedure/method/whatever?

Employees_Matrons_Brief (object_filters_columns, using a single word to describe (not define in detail) each set piece. Can be read 'the set of employees who are matrons, returned as the set of fields used in the brief display'). // Comment to note that brief means without age and sex but with full name, and matron means females older than 30.

{object_filters_columns seems like it can work, when there is a clear "main" object (or maybe we should say class?), but what do you use when 2 (or more) entities (classes, tables) are involved and all of them contribute with approximately the same number of fields? and what about order variations (ascending/descending, by different fields)?}

{Also, most of the current programming languages are "object oriented" making it hard to dynamically add or remove "field" from a class due to their lack of relational projection capabilities (and making it easy to "name things" as if they could be dominated by a class / noun as in the object_filters_columns / class_filters_columns suggestion, but when working in a relational (or pseudo relational/ SQL ) language, this nouns become irrelevant: the result of a relational operation could be a derived relvar (view) with 5 fields, each one coming from a different "base relvar" (tables), making it impossible to choose a particular base relvar as the one that should be used to name the query.}

DecemberTen