I want to join two tables(Table1,Table2) which should return the status of the references mentioned in table1 reference column(12,14,18,19). Table2 has information of the ID which are mapped to the reference in individual rows as shown below.
Table1:
Datatype of columns are: ID is of type integer,Name is character varying,reference is character varying,status is character varying.
ID Name reference status
10 PAX11 12,14,18 Undelivered
11 PAX193 Undelivered
12 ASD1 delivered
14 PAA delivered
90 PQA 19 Undelivered
18 PX Halt
19 ONA delivered
Table2:
Below 3 columns are of integer type.
sno ID reference
1 4 100
2 10 12
3 10 14
4 10 18
5 90 19
Your data model is wrong. You should put your effort into fixing it. The correct fix is to have another table, with one row per id and per sno. This is called a junction or association table.
What is wrong with the data model? The issue is the reference column. Let me count the ways:
A column should contain a single value, not multiple values.
The data type should be correct for a value, so a number should not be stored in a character column.
Foreign keys should be properly defined. You cannot do that with a string list.
Relational databases have relatively weak string processing capabilities.
Queries that use reference cannot make use of indexing, and statistics might be misleading.
Relational databases have these great constructs for storing lists. They are called tables, not strings.
Related
I am using PostgreSQL 12 and PostGIS.
The Behaviour I want
I have a table LOCATIONS which contains geographic data and a ROWID as Primary Key. I also have a table VALUES which contains arbitrary values. I want to map each entry in VALUES to either no or a single location. I can easily do this with a foreign key in VALUES referencing LOCATIONS.ROWID.
The problem
The issue I have is that my location data is spread across multiple tables (which I can't change). Is there a way to add a field to VALUES that references exactly one row under one of the location tables?
I think this would require a unique identifier across multiple location tables. However, I do not know how to achieve this, while not relying on the correctness of inserted data.
Table Format for clarification
VALUES
rowid
value
geoID
0
42
0
1
69
1
LOCATIONS A
rowid
name
geoID
geometry
0
USA
0
POLYGON(...)
1
UK
2
POLYGON(...)
LOCATIONS B
rowid
name
geoID
geometry
0
NYC
1
POLYGON(...)
1
LA
3
POLYGON(...)
I want to store about 100k rows of data, and all data some common field.
All data have a category and other fields is base on category.
For example if data is in category 1, It had extrafield1 and extrafield2
I search and found two way for storing data.
1-Name value pair
Table1
ID Name Category Field2 Field3
1 Name1 1 Value Value
2 Name2 2 Value Value
Table2
ID Table1_ID Name Value
1 1 extrafield1 1
2 1 extrafield2 2
3 1 extrafield3 3
4 2 extrafield4 4
5 2 extrafield5 5
2-Parent Child table
Table1
ID Name Category Field2 Field3
1 Name1 1 Value Value
2 Name2 2 Value Value
Tableforcategory1
ID Table1_ID extrafield1 extrafield2 extrafield3
1 1 1 2 3
Tableforcategory2
ID Table1_ID extrafield4 extrafield5
1 2 4 5
So my question is when use method 1 and when use method 2.
Method 2 is generally preferred for a variety of reasons:
It more closely models the entities represented by the different categories.
It allows for the columns to have different data types.
It makes it easier to implement check constraints for value-only columns.
It makes it easier to implement foreign key constraints for reference columns.
It makes it easier to implement unique constraints, should these be appropriate.
It makes it easier to implement not-NULL and default values.
It makes it easier to add columns on specific attribute values.
And there may be other reasons.
The first method -- which is called entity-attribute-value modeling (EAV) -- is definitely an alternative. It is mostly suitable in two situations:
The number of attributes exceeds the column limit in the database being used.
The attributes are sparsely populated, so only a few are in use for any given entity.
Sometimes a hybrid of these two methods is appropriate, with commonly used attributes being stored in a relational format and sparse attributes stored as EAV.
There are alternative approaches, such as storing the values in a JSON or XML object. These are not generally recommended, but might be suitable in some databases under certain circumstances -- particularly when all attributes need to be treated as a single block and returned and set together.
It depends on the type of queries and the stability of the data model.
If your queries are essentially static, meaning you know when you are going to use "extrafield_x", then method 1 is simpler and more efficient, but less flexible.
If you need more dynamic queries and in time you might more categories and more "extrafields", method 1 is more flexible, no data model maintenance required, but more complex to use and probably slower.
I just started using SQL and need to perform the following task.
1) First, I need to dupicate a table 100 times. For all these duplicated tables, I want to keep its content unchanged. But I also want to update the primary key by one.
2) Secend, I want to concatenate all these duplicated tables together by row, and also concatenate them to the original table by row.
Example: The original table looks like:
ID CATEGORY
1 A
2 B
… …
26 Z
And I want to duplicate this table, and concatenate it to the original one. I want to maintain the colums other than the primary key (ID here) unchanged, and update the primary key by one each time. I want to get:
ID CATEGORY
1 A
2 B
...
26 Z
27 A
...
52 Z
How to do this? Thanks!
I need to execute a crosstab/pivot query in SQL Server using columns of all varchar data types and one image data type. I have created a stored procedure that joins a series of tables in this format. "B" the only element that can be linked to image data. If the DATA field for "B" is blank, then there is also blank IMAGEDATA for that row.
OBJID CONTAINERID ELEMENT DATA IMAGEDATA
1 11 A a123 NULL
1 12 A aa123 NULL
1 11 B b123 0XFFD8FFE
1 12 B bb123 0XFFD8FFE
1 11 C c123 NULL
Then I use a pivot query. Ideally, the table should look like this:
OBJID CONTAINERID A B C IMAGEDATA
1 11 a123 b123 c123 0XFFD8FFE
1 12 aa123 bb123 0XFFD8FFE
Problem is that image data fields cannot be pivoted, grouped, converted, etc...I've tried converting the image to varchar from binary, but it gives me gibberish.
Restrictions:
1. "ELEMENTS" are dynamic, so the number of columns for the pivot table is always changing. (ie. It *could* go all the way from A to Z.)
2. The fields are to be used in an SSRS report, therefore I need to maintain the image data type
3. I can't use any other developer language (.NET, etc..)
Is there any other possible way to do this?
So it seems there is no other way to do this than to manually add/create the IMAGEDATA column as a last step. Here was my solution:
I used two separate tables: one pivot table without the IMAGEDATA column, and another table similar to the first one displayed in the question above. Once I made the queries for the pivot table, I put it into a temp table, added a column with an IMAGE data type, and made the matches to fill in the IMAGEDATA column.
Seems like a simple solution, but it is hardly maintainable nor efficient. I am not relying on much to match up the IMAGEDATA with the other fields, and what if I decide that more ELEMENTS will have IMAGEDATA?
I've recently been asked to rewrite a booking system that was not performing as well as a client would like. I've found the database schema / object mapping technique used to be quite unusual and was wondering if anyone else has come across anything similar.
The old system used about 25 classes for things like customers, appointments and orders etc, each of which has a unique property called 'class_id'.
When looking at the database, each class had a corresponding table, however none of them contained any foreign key fields although they had to be linked in some way as the application allowed the client to carry out various levels of reporting.
After further investigation, I noticed that the database contained another table called 'application_hierarchy'.
This table contained 4 columns which mapped out the relations between different records:
class_id - Which identified the record type
object_id - Which referenced the id of the record within its corresponding table
parent_class_id - Which identified the record type of the related record
parent_object_id - Which referenced the id of the parent record within its corresponding table
For example, if customer 5 has three different orders with id numbers 10, 11 and 12:
The Customer class was ID 4
The Order class was ID 7
So:
class_id | object_id | parent_class_id | parent_object_id
7 10 4 5
7 11 4 5
7 12 4 5
There would be a large number of rows in this table for every single object record in the application and these would be combined with a large join query to create the reports.
Trying to import this data into the new schema has been an absolute nightmare, mainly because the original author has neglected to document which class is identified by which id number!
Is this a commonly used technique or was the original developer just being a PITA?
Any advice / comments appreciated.
Thanks.
You might find you answer here : Stefan Tilkov: Thoughts on the Generic vs. Specific Tradeoff.