I have one table that has a list of Facilities, then I have many other tables, one for each Facility with the equipment that is there.
I am trying to make a query that can bring all of these tables together. The problem is that equipment names can be repeated from Facility to Facility so I need to get the Facility name to be associated with the equipment to have unique records. I do not have the ability to edit these equipment tables so I can't just add a column to the table and the only place that the Facility name is referenced in the Equipment Tables is in the title of the Table itself.
Is there any way that I can link the Facility Table records to the names of the Equipment Tables?
The Tables are similar to this:
Facilities
Column1
EI-456
EI-497
EI-456
Column1
Pump1
Pump2
FT1
EI-497
Column1
TT1
Pump1
Riser1
Hopefully that makes it a little more clear.
That looks like terrible design. You should have:
a Facilities table
an Equipments table (optional, depending on your needs)
a Locations table (or Assignment or...) where you just store the FacilityId and the EquipmentId.
I suggest that you read a bit about database normalisation. That will really pay off in the long run.
What you're asking for can be done dynamically through code (vba, etc) using your row record value to populate column.name in a query string.
I'd run an initial query to determine the facility name and then do:
Dim sillyString as String
sillyString = .row(?).item("column") = "EI-456"
strSQL = "SELECT * FROM " & sillyString & "WHERE ..."
Related
We have a software solution which is used by +200 customers. We recently switched to pgsql, because our former database was too slow handeling the search queries our customers use.
Our dabatabase looks like this:
TABLE A
1. ID
(+ some other fields which aren't important here)
TABLE B
This table is used to store 'data' on the items in table A. This is different for every customer. For example 'Type' can be 'CLIENTNAME' and value 'AZERTY'. One record on TABLE A can have infinite records in TABLE B. Mostly 1 record in Table A has between 5 - 10 records on Table B.
1. ID TABLE A
2. TYPE
3. VALUE
TABLE C
1. TABLE A ID
2. VERSIONNR
3. DESCRIPTION
This file has the different verions of the records in TABLE A. Each of these versions has an extended description. This can range from 0 characters to infinite.
Our problem: our customers are used on 'google-like' searching. For example: they type 'AZERTY' and we show all the records from TABLE A where the ID of TABLE A:
'AZERTY' is in the description of the most recent version of TABLE C
'AZERTY' is in one of the values of TABLE B
Additional problem: this search is a 'contains'. If they search 'ZER', they should also find the records with 'AZERTY' in it. Multiple arguments are an 'AND', if they search for 'ZER 123', we need to show all records where the description matches 'ZER' and '123' or the values match 'ZER' and '123'.
What we have done so far:
There is an option a user can check in/out whether they want to search the description or not. We mosty advice them to only search for the values and only use the description in case of need.
We make several search threads to the database for one search query, because searching all documents at once would take too much time.
Some time ago, on our former slow database engine, a collegue of mine made 'search tables', basically this is a table which contains all values on a TABLE A ID so there isn't need for any join in the SQL query when searching. It looks like this:
TABLE D
TABLE A ID
VALUES (all values from TABLE B for this TABLE A ID, seperated by a ' ')
DESCRIPTION (the description of the most recent version for this TABLE A ID)
Example record:
- 1
- ZER 123 CLIENT NAME NUMBER 7856 jsdfjklf 4556423
- DESCRIPTION CAN BE VERY LONG.
If a customer searches for 'ZER 123' this becomes:
"select TABLE_A_ID from TABLE_D where values like '%ZER%' and values like '%123%'"
Important:
Some of our customers have alot of records in TABLE A. +5.000.000, which means there are alot of records in TABLE B (+/- 50.000.000). Most of our customers have between 300.000 and 500.000 records in TABLE A.
My questions:
Is there a better / faster way to search through all the values then that search table? Without the search table i would have to make a join for every ' ' in the search argument of the customer, which will work too slow (i think?) if they have alot of records in TABLE A. For example:
select ID from TABLE_A
INNER JOIN TABLE_B Sub1 ON TABLE_A.ID = Sub1.TABLE_A_ID and Sub1.VALUE like '%ZER%'
INNER JOIN TABLE_B Sub2 on FILE_A.ID = Sub2.TABLE_A_ID and Sub2.VALUE like '%123%'
I have taken a look at the full text search in PGSQL. I don't think i can use it since you can't use it as like (= 'contains') ?
Is there any index I can use on the values (FILE B or search file) and description (FILE C or search file) to make the searches faster? I've read on it and i don't think there is any, because indexes aren't used when searching with "like '%ZER%'" ?
I hope i've explained this cleary.
Thanks in advance!
Your terminology is confusing, but I assume you mean "tables" when you write "files".
You cannot reasonably search in several tables with a single query, but you can search in several columns of a single table at the same time.
Based on your description, I would say that you need a trigram index on the concatenation of the relevant string columns in the table.
I have the following problem.
I have a table Entries that contains 2 columns:
EntryID - unique identifier
Name - some name
I have another EntriesMapping table (many to many mapping table) that contains 2 columns :
EntryID that refers to the EntryID of the Entries table
PartID that refers to a PartID in a seprate Parts table.
I need to write a SP that will return all data from Entries table, but for each row in the Entries table I want to provide a list of all PartID's that are registered in the EntriesMapping table.
My question is how do I best approach the deisgn of the solution to this, given that the results of the SP would regularly be processed by an app so performance is quite important.
1.
Do I write a SP that will select multiple rows per entry - where if there are more than one PartID's registered for a given entry - I will return multiple rows each having the same EntryID and Name but different PartID's
OR
2.
Do I write a SP that will select 1 row per entry in the Entries table, and have a field that is a string/xml/json that contains all the different PartID's.
OR
3. There is some other solution that I am not thinking of?
Solution 1 seems to me to be the better way to go, but I will be passing lots of repeating data.
Solution 2 wont pass extra data, but the string/json/xml would need to be processed additionally, resuling in larger cpu time per item.
PS: I feel like this is quite a common problem to solve, but I was unable to find any resource that can provide common solutions or some pros/cons to different approaches.
I think you need simple JOIN:
SELECT e.EntryId, e.Name, em.PartId
FROM Entries e
JOIN EntriesMapping em ON e.EntryId = em.EntryId
This will return what you want, no need for stored procedure for that.
I have two tables as seen below:
ORDER
ITEM_DESCRIPTION
What I want to do is write a query where I can pull the ticket number and item but have the item show what it actually is instead of the item code. So far I have this:
SELECT
TICKET_NUMBER,
ITEM
FROM ORDER
Any help would be awesome!
SELECT
[ORDER].TICKET_NUMBER,
ITEM_DESCRIPTION.ITEM
FROM [ORDER]
INNER JOIN ITEM DESCRIPTION ON (Order.ITEM=ITEM_DESCRIPTION.CODE)
Additional Tips:
"ORDER" is less than ideal for a table name because it is a SQL reserved word.
ID and Code seem to be redundant in your ITEM_DESCRIPTION table. Ditch the ID and make the CODE field the primary key of ITEM_DESCRIPTION.
The ITEM_DESCRIPTION table probably should be named "ITEM" because inevitably you will want to add more columns to describe items.
First Name and Last name should not be in your Order table. You should create a separate Customers table, move the name columns to the new table, and then link to it with a customer ID.
As sstan said in the comment. If you are going to be doing much SQL you really need to learn the syntax for JOIN operations. They are very critical to understanding SQL.
I have 2 tables in MS Access, that are updated externally each day (any tables I add will be deleted when the copy arrives in the morning):
Current status of a customer
All customer errors
The current status of a customer includes all customers in a particular process, and shows which status they are in today. The "all customer errors" table shows the details of customers IF they had an error at some stage. Both tables have some fields in common, but not everything (so a simple union isn't possible).
I need some help to do the following:
Join the tables and create a column stating the initial table they came from. I realise I will have some duplicates.
Taking "current status of a customer" table, populate the missing data from "all customer errors"
create an extra column - "number of errors" where I count the number of times the customer appeared in the error table
Help!
My SQL skills are a bit basic, but improving each day :-)
Thanks
Kirstin
You must have a primary key and create an inner join. Use this formula in the SQL tab. You can then go into design view and use 'make table'. Simply select what data you want to appear.
'SELECT column_name(s)
FROM table1
INNER JOIN table2
ON table1.column_name=table2.column_name;'
When you have your new table you can update it to have new columns etc.
'UPDATE table_name
SET column1=value1,column2=value2,...
WHERE some_column=some_value;'
I was wondering how can you display multiple values in a database for example, lets say you have a user who will fill out a form that asks them to type in what types of foods they like for example cookies, candy, apples, bread and so on.
How can I store it in the MySQL database under the same field called food?
How will the field food structure look like?
You may want to read the excellent Wikipedia article on database normalization.
You don't want to store multiple values in a single field. You want to do something like this:
form_responses
id
[whatever other fields your form has]
foods_liked
form_response_id
food_name
Where form_responses is the table containing things that are singular (like a person's name or address, or something where there aren't multiple values). foods_liked.form_response_id is a reference to the form_responses table, so the foods liked by the person who has response number six will have a value of six for the form_response_id field in foods_liked. You'll have one row in that table for each food liked by the person.
Edit: Others have suggested a three-table structure, which is certainly better if you are limiting your users to selecting foods from a predefined list. The three-table structure may be better in the case that you are allowing them the ability to enter their own foods, though if you go that route you'll want to be careful to normalize your input (trim whitespace, fix capitalization, etc.) so you don't end up with duplicate entries in that table.
normally, we do NOT work out like this. try to use a relation table.
Table 1: tbl_food
ID primary key, auto increment
FNAME varchar
Table 2: tbl_user
ID primary key, auto increment
USER varchar
Table 3: tbl_userfood
RID auto increment
USERID int
FOODID int
Use similar format to store your data, instead a chunk of data fitted into a field.
Querying in these tables are easier than parsing the chunk of data too.
Use normalization.
More specifically, create a table called users. Create another called foods. Then link the two tables together with a many-to-many table called users_to_foods referencing each others foreign keys.
One way to do it would be to serialize the food data in your programming language, and then store it in the food field. This would then allow you to query the database, get the serialized food data, and convert it back into a native data structure (probably an array in this case) in your programming language.
The problem with this approach is that you will be storing a lot of the same data over and over, e.g. if a lot of people like cookies, the string "cookies" will be stored over and over. Another problem is searching for everyone who likes one particular food. To do that, you would have to select the food data for each record, unserialize it, and see if the selected food is contained within. This is a very inefficient.
Instead you'll want to create 3 tables: a users table, a foods table, and a join table. The users and foods tables will contain one record for each user and food respectively. The join table will have two fields: user_id and food_id. For every food a user chooses as a favorite, it adds a record to the join table of the user's ID and the food ID.
As an example, to pull all the users who like a particular food with id FOOD_ID, your query would be:
SELECT users.id, users.name
FROM users, join_table
WHERE join_table.food_id = FOOD_ID
AND join_table.user_id = users.id;