A table in SQLite DB contains 52 columns and their name as follows
size0,size1,size2,size3,....size49,category,priority.
while preparing the query for getting the values in only sizes columns i'm writing the query as
select size0,size1,size2,size3,....size49 from myTableName.
Can we prepare these column names dynamically in a loop( because all size columns are in logical order ) within the query it self?
and that query should work in sqlite.
Any comments or suggestions would be appreciated.
Thank you in advance.
In SQLite, you can't change columns number or column definition in a query with plain SQL.
Anyways, this MUST be a horrible database design. Consider normalizing your schema, as I can't believe 200 size columns is a correct solution to any real problem.
you could do
SELECT * FROM mytablename
The * will return all data (columns) from the table.
Related
What is a good way to "select" from multiple tables at once when the list of tables is not known in advance in snowflake sql?
Something that simulates
Select * from mytable*
which would fetch same results as
Select * from mytable_1
union
Select * from mytable_2
...
I tried doing this in a multistep.
show tables like 'mytable%';
set mytablevar =
(select listagg("name", ' union ') table_
from table(result_scan(last_query_id())))
The idea was to use the variable mytablevar to store the union of all tables in a subsequent query, but the variable size exceeded the size limit of 256 as the list of tables is quite large.
Even if you do not hit 256 character limits, it will not help you to query all these tables. How will you use that session variable?
If you have multiple tables which have the same structure, and hold similar data that you need to query together, why are the data not in one big table? You can use Snowflake's clustering feature to distribute data based on a specific column to your micro-partitions.
https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions.html
Anyway, you may create a stored procedure which will create/replace a view.
https://docs.snowflake.com/en/sql-reference/stored-procedures-usage.html#dynamically-creating-a-sql-statement
And then you can query that view:
CALL UPDATE_MY_VIEW( 'myview_name', 'table%' );
SELECT * FROM myview_name;
Does anyone know how to concatenate all the values of a column in a query using SQL only? I know that there are ways using database specific tools such as pivot, but I don't think I have access to something like that in infomaker.
I am using infomaker to produce labels for sample bottles. The bottles can be analysed for more than one thing. If I join the bottle and analysis tables I get several rows per bottle which results in multiple labels, so I was hoping to concatenate all the values for the analysis using SQL and then use a computed value based on this to add something useful to the label. I can only use 1 transaction based on a select query to do this.
Adding additional tables or columns to the database would be highly discouraged.
In some oracle version you can use wm_concat
SELECT field1, wm_concat(field2) FROM YourTable
GROUP BY field2;
otherwise you can use listagg
My table contain 97 column with data type varchar(200) about 80% and bigint,char.
select count(*) from mytable it return
4500 rows
I am testing with 100 rows with SQL statement
select * from mytable .It use time about 2.3 min
I think,it is too very slow if return all record
please recommend me for the way to up speed my query and result.
my db server is db2 9.5
The first thing you should do to improve the performance is stop using SELECT *. Rewrite the query to get the columns you need.
the second thing to do is to add a WHERE clause. Do you really need to return all rows for the table?
Third thing is indexes, does you table have any, can you use indexed columns in your WHERE statement, etc.
What is the reason not to use select *?
http://weblogs.asp.net/jgalloway/archive/2007/07/18/the-real-reason-select-queries-are-bad-index-coverage.aspx
You need to isolate what is slow, the query or displaying the query. I am assuming it is a combination of both.
When you have 97 columns each being a varchar(200) sql cannot store all the info on the same row in a page . The worst case scenario is 97 * 202 (i used 202 instead of 200 because sql needs to store the length of a varchar in each column and i believe it stores it as two bytes) 19594 which is much larger than the row on a page can handle. TL;DR; normalize your table and have the columns broken up into logical units on another table.
Also doing a SELECT * FROM X will result in a full table scan which is much slower then querying on an indexed column.
If you must do a SELECT * FROM X and you have to have 97 columns please change the column data types to be a smaller data type (int,tinyint,char(10)) this will optimize the storage and should speed up the query.
I am trying to display the RowID alongside all columns from a Select * statement.
I am using Oracle with Toad to run the SQL statement.
I have two tables that I need to compare, but I do not have any unique identifiers to use when sorting the two tables for comparison. So I thought that using the RowID to sort the two tables in order to compare them could help.
Is there a way to add RowID to a Select * statement? I cannot add all the columns names as there are over 50 of them. I will be doing this to multiple sets of tables where the number and name of columns will vary.
Any help or ideas around this would be greatly appreciated.
Thanks in advance,
Marwan
You can do something like
SELECT rowid, a.*
FROM table_name a
But I'm not sure that is actually going to help you. Sorting the data on ROWID is not going to be particularly useful since that is just a physical location on disk. It's just as arbitrary as presenting the data unsorted.
Ok, here is my dilemma I have a database set up with about 5 tables all with the exact same data structure. The data is separated in this manner for localization purposes and to split up a total of about 4.5 million records.
A majority of the time only one table is needed and all is well. However, sometimes data is needed from 2 or more of the tables and it needs to be sorted by a user defined column. This is where I am having problems.
data columns:
id, band_name, song_name, album_name, genre
MySQL statment:
SELECT * from us_music, de_music where `genre` = 'punk'
MySQL spits out this error:
#1052 - Column 'genre' in where clause is ambiguous
Obviously, I am doing this wrong. Anyone care to shed some light on this for me?
I think you're looking for the UNION clause, a la
(SELECT * from us_music where `genre` = 'punk')
UNION
(SELECT * from de_music where `genre` = 'punk')
It sounds like you'd be happer with a single table. The five having the same schema, and sometimes needing to be presented as if they came from one table point to putting it all in one table.
Add a new column which can be used to distinguish among the five languages (I'm assuming it's language that is different among the tables since you said it was for localization). Don't worry about having 4.5 million records. Any real database can handle that size no problem. Add the correct indexes, and you'll have no trouble dealing with them as a single table.
Any of the above answers are valid, or an alternative way is to expand the table name to include the database name as well - eg:
SELECT * from us_music, de_music where `us_music.genre` = 'punk' AND `de_music.genre` = 'punk'
The column is ambiguous because it appears in both tables you would need to specify the where (or sort) field fully such as us_music.genre or de_music.genre but you'd usually specify two tables if you were then going to join them together in some fashion. The structure your dealing with is occasionally referred to as a partitioned table although it's usually done to separate the dataset into distinct files as well rather than to just split the dataset arbitrarily. If you're in charge of the database structure and there's no good reason to partition the data then I'd build one big table with an extra "origin" field that contains a country code but you're probably doing it for legitimate performance reason.
Either use a union to join the tables you're interested in http://dev.mysql.com/doc/refman/5.0/en/union.html or by using the Merge database engine http://dev.mysql.com/doc/refman/5.1/en/merge-storage-engine.html.
Your original attempt to span both tables creates an implicit JOIN. This is frowned upon by most experienced SQL programmers because it separates the tables to be combined with the condition of how.
The UNION is a good solution for the tables as they are, but there should be no reason they can't be put into the one table with decent indexing. I've seen adding the correct index to a large table increase query speed by three orders of magnitude.
The union statement cause a deal time in huge data. It is good to perform the select in 2 steps:
select the id
then select the main table with it