Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm using Oracle, this information comes from the "HR.EMPLOYEES" table, but I don't know how to structure that query.
There are several ways to achieve your goal. In no particular order:
Using SUBSTR
Just use SUBSTR. This function allow you to extract a part from a string:
SELECT first_name FROM table WHERE SUBSTR(last_name, 2, 1) = 'o'
Remember, you are only filtering the rows based on lower case as 'o' which is not same as upper case 'O'. And, you need to create a function-based index on the column too, to avoid any performance issues due to FTS.
If you have only one column for the name, then use SUBSTR and INSTR in the SELECT to get the first_name. I would like to leave this up to you. Let me know if you really struggle with INSTR. A hint for you to try and learn yourself, INSTR( string, substring [, start_position [, nth_appearance ] ] )
Using regular expression
The same could be achieved using REGEXP_LIKE, however, it would be much resource consuming:
SELECT first_name FROM table WHERE REGEXP_LIKE(last_name, '^.o')
Here, I am looking for a string such as:
^ after the start of the string
. I have any character
o then an o
Using LIKE pattern matching
This solution is rather database-vendor agnostic: it will work with (almost?) any RDBMS:
SELECT first_name FROM table WHERE last_name LIKE '_o%'
Pattern matching is more or less like the wildcard you might use in your shell. Except than is SQL _ is used for any character and % is used for any string (incl. empty string).
Other
By searching through the web and in various Oracle's documentation you might probably be able to find several other -- more or less exotic -- options.
For example, one might think of using a virtual column on the second letter of last_name.
Or, if and only if, you need case insensitive approach, you can have a look at this demo http://lalitkumarb.wordpress.com/2014/01/22/oracle-case-insensitive-sorts-compares/. Please make sure you have utmost understanding about the trivial aspects as mentioned above, before jumping onto complex things.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 16 hours ago.
Improve this question
I saw some code of people where they were used number of columns instead of names.
As i found out in old question:
Can i use column number instead of column name in where condition of a select query in SQL Server 2005?
There were not any good oppinions about this type of selecting instead of one with inline view approach.
It's few years later now.
Do you know any good reason to use number of columns instead of column names?
I would like to be assured that selecting columns by names instead number of column is the best approach in every case. Second option is to learn new specific approaches which shows usefulness of numbering columns during selection.
No, there is no good reason to refer to a column by its ordinal position instead of its name.
Nothing has changed that since the question you linked to was answered.
Some implementations of SQL allow the ordinal to refer to a column in the ORDER BY clause, but this is actually deprecated. It is removed in the ANSI/ISO SQL standard, and it is discouraged in most implementations.
https://dev.mysql.com/doc/refman/8.0/en/select.html:
Use of column positions is deprecated because the syntax has been removed from the SQL standard.
https://learn.microsoft.com/en-us/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver16#best-practices
Avoid specifying integers in the ORDER BY clause as positional representations of the columns in the select list. For example, although a statement such as SELECT ProductID, Name FROM Production.Production ORDER BY 2 is valid, the statement is not as easily understood by others compared with specifying the actual column name. In addition, changes to the select list, such as changing the column order or adding new columns, requires modifying the ORDER BY clause in order to avoid unexpected results.
https://www.postgresql.org/docs/current/sql-select.html
The ordinal number refers to the ordinal (left-to-right) position of the output column. This feature makes it possible to define an ordering on the basis of a column that does not have a unique name. This is never absolutely necessary because it is always possible to assign a name to an output column using the AS clause.
If some of the group by condition are derived columns, NOT all DB query engines (such as Presto) will accept name alias of derived columns in the same select clause. In that case, using the column number is a more straight-forward approach compared to another level of nested query to get name alias recognized by DB query engines.
Using column number for derived columns in group by condition
SELECT
name,
case
when age>=18 then 'adult'
else 'kid'
end as customer_type,
count(1) as num_orders
from
orders
group by 1,2
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So this isn't a technical question, but rather questioning why a language is designed the way it is.
I've been learning SQL and one thing that's been bothering me greatly is how SQL asks you to name the column you want and THEN name the table you want to get it from. To me, it would make more sense that you refer to the parent body (which is the table) and THEN the column it has. But SQL seems to forces users to do it the other way around. Why?
I'm just curious as to why the language is designed this way.
SELECT column
FROM table
why not
FROM table
SELECT column
SQL tries to mimic English language to some extent, so that it feels natural to formulate the query.
In spoken English you would say something like "I want the names of the employees". You would not say "I want of the employees their names" or something like that.
But you are right, it might have been a good idea to have the query represent the order of execution. And "From the employee table I want the names" would not be so far off the mark :-)
SQL is a descriptive language, not a procedural language. It describes the result set being produced. And, you can think of that result set as a report, with column headers.
As such, the basic querying construct returns those column headers. The rest of the query describes how they are produced.
You may find this post useful. Starting with FROM is the most logical way to think about a query (Why would anyone write SELECT before knowing what to SELECT from?). However, SQL guidelines were designed as if your query were a command. Thus, you are commanding the system to SELECT the data for you, and the FROM further specifies that command.
Of course, the actual execution is distinct from the lexical and logical orders above.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have noticed that some people in database columns instead of for example id, user, addressare using something like h_id, e_user, f_address etc...
Is that some kind of security aspect? or maybe these are some shortcuts of words?
Its because there might be many id fields like user_id,category_id,that's why they use so that code is understandable.
And talking about columns name like f_address, they are just shortcut for say first address. It doesn't have anything to do with security but to increase the query readability use proper name to fields so that people can understand just by seeing column name what data it saves.
If there are fields like category_id and sub_category_id , it is understandable from the field name, but if i denote it using c_id and s_id, its hard to depict.
Well, 'User' is a security object in SQL Server, so using that is kind of scary. 'ID' and 'address' are way too generic to provide any semantics when used as attribute names.
If a purpose of design is to be maintainable and readable, then there some words that simply don't work.
Definitely not security related.
Some use it for readability or speed (you don't have to remember which table you gave a certain name->see following example) when writing queries.
i.e.
select a.name, b.name from table1 a join table2 b on a.id=b.id
Like this you have to remember that table1 is named a and table2 is named b etc.
But if you use tablename_field (which you can shorten by using only the first letter of the tablename). That way you never have duplicate fieldnames when creating join queries.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Hi guys so I have a question about nick name searches.
I have a very large database and in my Accounts Entity I have a firstname column. When a user searches for an account by first name, it is possible that they may be using a nickname. For example searching for Bob, should also return Robert.
The way I would think to do this would be to create a table called nickname, with two columns, the nickname, and name. That way we map bob->robert.
Then when doing the query make the where clause look like this "WHERE firstname IN (SELECT name FROM nickname WHERE nickname = 'bob')"
The two problems I have is, the query above seems very inefficient, and would be very slow over large data sets (I could be wrong here so please tell me if so, when I say large data set I mean 14 million rows).
The Second problem I have is where to get the Nickname data from. This is the only thing I have found so far: https://code.google.com/p/nickname-and-diminutive-names-lookup/downloads/list
Any help would be greatly appreciated.
One option would be to use full text search instead:
http://www.postgresql.org/docs/current/static/textsearch.html
This would allow you to add custom dictionaries, among other colorful features:
http://www.postgresql.org/docs/current/static/textsearch-dictionaries.html
I had to solve a similar problem. We had a table with name variations that were linked to an individual. This was for a database of authors.
We then created a mapping table with soundex and double metaphone entries for these names (pre-generated) then did queries against that table to find individuals.
If you're not familiar with soundex or double metaphone, they are phonetic algorithms to match when using misspellings and similiar names. Soundex was developed for the US Census.
In our case, we already had the variations of every name the person published as rather than a generic list of names. However, the soundex algorithm can help with similar spellings. You'll still need to get a nickname list from somewhere, but this should help with the performance.
The reason I suggested two algorithms is that we had a lot of collisions using just one, but with both of those together it was a rather good filter. Double Metaphone worked better for non Western European names.
I'd suggest adding a front end element to let your customer service people (or customers) add their nickname too. Customers can help you build up a nickname list and you can use known nicknames to help with fuzzy searches on others eventually.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
Just for reference I am using SQL Azure.
I noticed when I am trying to select data from a table based on a license plate and the state of that plate I get no results back if the state is "IN". I realize the word "IN" is reserved in SQL server; however, I am containing that within quotes in my query. I currently am in testing phase and have only one record in the table which has a lisence plate 287YGB and state IN.
If I write my query as follows I get nothing back.
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles WHERE tblVehicles.Lisence = '287YGB' AND tblVehicles.PlateState = 'IN'
If I write my query this way I get back my result. But this is not good enough.
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles WHERE tblVehicles.Lisence = '287YGB'
And finally, if I write my query this way I get the only row in the table.
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles
From these tests I can see that the last where parameter is causing the problem. I am assuming it is due to the fact that the word "IN" is reserved. Is there a way around this?
Reserved words usually only cause problems if you're using them as field names, and in that case you need to wrap them with brackets ("[]") to eliminate the problem. I will amost guarantee you that your PlateState has some garbage in it, so you need to either trim it first (LTRIM(RTRIM(PlateState)) = 'IN') or use Like '%IN%' instead, and this will return the results you expect.
try this
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles WHERE tblVehicles.Lisence = '287YGB' AND LTRIM(RTRIM(tblVehicles.PlateState)) = 'IN'