First, just simple question: Is there something as "EVAL()" function in Informix?
And now if anyone is interested there is real world problem where I need EVAL() function:
So, I have two tables in DB:
Fist table (main one) is sales_data(data_id, data_val_id, other, columns, ...)
Second table is for_select(data_id, select_part, from_part, where_part, key_column_name)
Problem is that in first table I don't have all data that I need. Additional data is in other tables depending on "data_id" and "data_val_id" columns in first table.
So, second table is for creating SQL SELECT to get those additional data from other tables.
Now I need to create SQL query like this (but I think that there is no EVAL function in Informix):
SELECT
data_id,
data_val_id,
(SELECT
EVAL(SELECT select_part FROM for_select WHERE data_id=sales_data.data_id)
FROM
EVAL(SELECT from_part FROM for_select WHERE data_id=sales_data.data_id)
WHERE
EVAL(SELECT where_part FROM for_select WHERE data_id=sales_data.data_id)
AND
EVAL(SELECT key_column_name FROM for_select WHERE data_id=sales_data.data_id) = sales_data.data_val_id
) AS additional_data
FROM
sales_data
I don't know who came up with this idea but it is not mine and I can't chage it...
I did tried to do this in PHP with dynamic SQL queries but it is veeery slow. For every row in results from main table PHP must connect to server and send new query. It is very slow and in main table I have around 50000 rows and I have 4 more this "additional_data" columns (grand total 5 "data_id" and "data_val_id" columns in main table).
Can someone help me? Is this posible in one SELECT? Is there something as "EVAL()" function in Informix?
-------- more explanations ---------
Every row in for_select table is very diferent from each other. Data in sales_data table is from our selling (our job) and final report (joined main and additional data) must have all columns. This is something that we can't change, report must look how it looks now and must have all data that have now. I just need to find a way to export it quicker than now.
I will try to write example: In DB we have tables for warehouses, for goods, for clients, for workers, for cars, ... and every row in for_select table is for one of this tables. Table for_select have 54 rows, so this means that we have 54 tables that we need additional data from to put in final report.
In sales_data we only have 5 columns that can be used for 5 diferent things depending on data_id column but I have 54 posible "things" that can be there, so comination of data_id (what table is used for "additional data") and data_val_id (what row from that table) determine what will be in final report. In real life data_id is for diferent type of goods that we sell and therefore for every diferent goods we need to show diferent "additional data" in addition to basic data: number of selled items, price,...
So, why we need for_select table, you ask? Because every table for additional data have diferent names for columns and in diferent place. Table cars have car_id, car_model columns but table warehouses have wh_id,wh_location and wh_name columns, from cars table I ony need car_model column but from warehouses I need wh_location||wh_name together (concated).
Tables names and data are in Serbian and names are not informative at all, so I did my best to translate it to English so you all can understand. Raw data will just confuse you all...
This question already has answers here:
mysql table with 40+ columns
(4 answers)
Closed 5 years ago.
Mysql tables.
phones
| ID | Name //5-6 columns
Specifications
| ID |phone_id| ram | camera | price |network // 50 columns approx
Now my specification table has 50 columns so far, so I need a suggestion how to handle this sort of situation ? Do I need to create some other tables to split specifications table or can I continue with this?
I need a better suggestion for better speed and performance.
Dealing with more than 50+ columns will not be best approach-
Data-Base operation like insert, update, select could take time.
Its became difficult task to handle the data when you are dealing
with 50+ columns in the table.
So I suggest do not continue with adding columns into the tables. mysql-table-with-40-columns could be usefull to solve your problems.
Perhaps you can have 1 main table with id, name, date and some more post specific stuff.
Then you could create 1 meta_table wich contains the id, main_id (this links to the post in your main table), meta_name (i.e.: price or color or dimensions), meta_value (i.e.: 125,95 or black or 150 x 50 x 8).
This way you can make as many column-like values stored into 1 table wich gets linked to 1 main table using an id.
This is the same concept as wordpress is using.
Otherwise you could also use something called serialized data/arrays into your main table, this is 1 column field with many array keys and their values.
I am building a LAMP system. My database will have at least 1 Million rows.
My query is:-
Each individual row in the database will have like 8-10 categories. Each type of category will have a predefined number. For example - 1 = India, 2 = USA, 3 = UK,etc
So will it be add these individual categories in each row in different row of MYSQL or will it be better to put all the concerned categories for an individual row in one MYSQL row separated by commas.
Which of the above system is more efficient storage wise and processing wise.
Thanks
Vishal ved
you may use an other table for handling category types (enumeration) and create a foreign key
which you can pass it your row
this will decrease overall insertion size and improve your overall efficiency.
also add index to the category id field. 1 million is not a count for a properly indexed table
I have two database tables.
The following query is selecting rows where the member_id and type match the query, then I am joining the two tables to get only entries that don't exist in the second, or exist but don't have NULL as portfolio_id.
This is working well.
$this->EE->db->select('submissions.entry_id');
$this->EE->db->from('submissions');
$this->EE->db->join('judging', 'submissions.entry_id = judging.entry_id', 'left');
$this->EE->db->where('submissions.member_group', $member_group);
$this->EE->db->where('submissions.type_id', '1');
$this->EE->db->where('judging.entry_id', NULL);
$this->EE->db->or_where('judging.portfolio_id IS NOT NULL');
$query = $this->EE->db->get();
The final part of my query has me completely stumped.
In the first table, a column named 'portfolio_name' can have a number between 1 and 7.
I need to retrieve 3 rows that have the same number in this column. If there are only two rows that match they must be ignored, like wise if there is 4 etc
How can this be achieved, without targeting an exact number?
Thank you
I working on a food database, every food has a list of properties (fats, energy, vitamins, etc.)
These props are composed by 50 different columns of proteins, fat, carbohydrates, vitamins, elements, etc.. (they are a lot)
the number of columns could increase in the future, but not too much, 80 for extreme case
Each column needs an individual reference to one bibliography of a whole list from another table (needed to check if the value is reliable or not).
Consider the ids, should contain a number, a NULL val, or 0 for one specific exception reference (will point to another table)
I've though some solution, but they are very different eachothers, and I'm a rookie with db, so I have no idea about the best solution.
consider value_1 as proteins, value_2 as carbohydrates, etc..
The best (I hope) 2 alternatives I thought are:
(1) create one varchar(255?) column, with all 50 ids, so something like this:
column energy (7.00)
column carbohydrates (89.95)
column fats (63.12)
column value_bil_ids (165862,14861,816486) ## as a varchar
etc...
In this case, I can split it with "," to an array and check the ids, but I'm still worried about coding praticity... this could save too many columns, but I don't know how much could be pratical in order to scalability too.
Principally, I thought this option usual for query optimization (I hope!)
(2) Simply using an additional id column for every value, so:
column energy (7.00)
column energy_bibl_id (165862)
column carbohydrates (89.95)
column carbohydrates_bibl_id (14861)
column fats (63.12)
column fats_bibl_id (816486)
etc...
It seems to be a weightful number of columns, but much clear then first, especially for the relation of any value column and his ID.
(3) Create a relational table behind values and bibliographies, so
table values
energy
carbohydrates
fats
value_id --> point to table values_and_bibliographies val_bib_id
table values_and_bibliographies
val_bib_id
energy_id --> point to table bibliographies biblio_id
carbohydrates_id --> point to table bibliographies biblio_id
fats_id --> point to table bibliographies biblio_id
table bibliographies
biblio_id
biblio_name
biblio_year
I don't know if these are the best solutions, and I shall be grateful if someone will help me to bring light on it!
You need to normalize that table. What you are doing is madness and will cause you to loose hair. They are called relational databases so you can do what you want without adding of columns. You want to structure it so you add rows.
Please use real names and we can whip a schema out.
edit Good edit. #3 is getting close to a sane design. But you are still very unclear about what a bibliography is doing in a food schema! I think this is what you want. You can have a food and its components linked to a bibliography. I assume bibliography is like a recipe?
FOODS
id name
1 broccoli
2 chicken
COMPONENTS
id name
1 carbs
2 fat
3 energy
BIBLIOGRAPHIES
id name year
1 chicken soup 1995
FOOD_COMPONENTS links foods to their components
id food_id component_id bib_id value
1 1 1 1 25 grams
2 1 2 1 13 onces
So to get data you use a join.
SELECT * from FOOD_COMPONENTS fc
INNER JOIN COMPONENTS c on fc.component_id = c.id
INNER JOIN FOODS f on fc.foods_id = f.id
INNER JOIN BIBLIOGRAPHIES b on fc.bib_id = b.id
WHERE
b.name = 'Chicken Soup'
You seriously need to consider redesiging your database structure - it isn't recommended to keep adding columns to a table when you want to store additional data that relates to it.
In a relational database you can relate tables to one another through the use of foreign keys. Since you want to store a bunch of values that relate to your data, create a new table (called values or whatever), and then use the id from your original table as a foreign key in your new table.
Such a design that you have proposed will make writing queries a major headache, not to mention the abundance of null values you will have in your table assuming you don't need to fill every column..
Here's one approach you could take to allow you to add attributes all day long without changing your schema:
Table: Food - each row is a food you're describing
Id
Name
Description
...
Table: Attribute - each row is a numerical attribute that a food can have
Id
Name
MinValue
MaxValue
Unit (probably a 'repeating group', so should technically be in its own table)
Table: Bibliography - i don't know what this is, but you do
Id
...
Table: FoodAttribute - one record for each instance of a food having an attribute
Food
Attribute
Bibliography
Value
So you might have the following records
Food #1 = Cheeseburger
Attribute #1 = Fat (Unit = Grams)
Bibliography #1 = whatever relates to cheeseburgers and fat
Then, if a cheeseburger has 30 grams of fat, there would be an entry in the FoodAttribute table with 1 in the Food column, 1 in the Attribute column, a 1 in the Bibliography column, and 30 in the Value column.
(Note, you may need some other mechanisms to deal with non-numeric attributes.)
Read about Data Modeling and Database Normalization for more info on how to approach these types of problems...
Appending more columns to a table isn't recommended nor popular in the DB world, except with a NoSQL system.
Elaborate your intentions please :)
Why, for the love of $deity, are you doing this by columns? That way lies madness!
Decompose this table into rows, then put a column on each row. Without knowing more about what this is for and why it is like it is, it's hard to say more.
I re-read your question a number of times and I believe you are in fact attempting a relational schema and your concern is with the number of columns (you mention possibly 80) associated with a table. I assure you that 80 columns on a table is fine from a computational perspective. Your database can handle it. From a coding perspective, it may be high.
Proposed (1) Will fail when you want to add a column. You're effectively storing all your columns in a comma delimited single column. Bad.
I don't understand (2). It sounds the same as (3)
(3) is correct in spirit, but your example is muddled and unclear. Whittle your problem down to a simple case with five columsn or something and edit your question or post again.
In short, don't worry about number of columns right now. Low on the priority list.
If you have no need to form queries based on arbitrary key/value pairs you'd like to add to every record, you could in a pinch serialize()/unserialize() an associative array and put that into a single field