question_id | person_id | question_title | question_source | question_likes | question_dislikes | created_at
-------------+-----------+--------------------------+--------------------------+----------------+-------------------+---------------------------------
2 | 2 | This is question Title 1 | This is question Video 1 | | | 2021-11-11 10:32:53.93505+05:30
3 | 3 | This is question Title 1 | This is question Video 1 | | | 2021-11-11 10:32:58.69947+05:30
1 | 1 | This is question Title 1 | This is question Video 1 | {2} | {1} | 2021-11-11 10:32:45.81733+05:30
I'm trying to add values inside the question_likes and question_dislikes which are arrays. I'm not able to figure out the query to add only non duplicate items inside the array using sql. I want all items in the array to be unique.
Below is the query i used to create the questions table:
CREATE TABLE questions(
question_id BIGSERIAL PRIMARY KEY,
person_id VARCHAR(50) REFERENCES person(person_id) NOT NULL,
question_title VARCHAR(100) NOT NULL,
question_source VARCHAR(100),
question_likes TEXT[] UNIQUE,
question_dislikes TEXT[] UNIQUE,
created_at TIMESTAMPTZ DEFAULT NOW()
);
UPDATE questions
SET question_likes = array_append(question_likes,$1)
WHERE question_id=$2
RETURNING *
What changes can i make to the above query to make it work?
This is a drawback of using a de-normalized model. Just because Postgres supports arrays, doesn't mean that they are a good choice to solve problems that are better solved using best practices of relational data modeling.
However, in your case you can simply prevent this by adding an additional condition to your WHERE clause:
UPDATE questions
SET question_likes = array_append(question_likes,$1)
WHERE question_id=$2
AND $1 <> ALL(question_likes)
RETURNING *
This prevents the update completely if the value of $1 is found anywhere in the array.
That's my first time using Firebird. I am trying to create this table. I checked the docs and it seems ok. What's wrong?
CREATE TABLE ENDERECO
(
ID_ENDERECO INTEGER generated by default as identity primary KEY,
RUA VARCHAR(50),
BAIRRO VARCHAR(35),
CEP VARCHAR(10),
COMPLEMENTO VARCHAR(35),
ECOMERCIO INTEGER(1),
ESTADO CHAR(2)
)
The problem is your use of INTEGER(1). The data type INTEGER (and SMALLINT and BIGINT) do not have a precision in their definition. See also Data Type Declaration Syntax in the Firebird 3 Language Reference:
<domain_or_non_array_type> ::=
<scalar_datatype>
| <blob_datatype>
| [TYPE OF] domain
| TYPE OF COLUMN rel.col
<scalar_datatype> ::=
SMALLINT | INT[EGER] | BIGINT
| FLOAT | DOUBLE PRECISION
| BOOLEAN
| DATE | TIME | TIMESTAMP
| {DECIMAL | NUMERIC} [(precision [, scale])]
| {VARCHAR | {CHAR | CHARACTER} VARYING} (length)
[CHARACTER SET charset]
| {CHAR | CHARACTER} [(length)] [CHARACTER SET charset]
| {NCHAR | NATIONAL {CHARACTER | CHAR}} VARYING (length)
| {NCHAR | NATIONAL {CHARACTER | CHAR}} [(length)]
In short, use:
CREATE TABLE ENDERECO
(
ID_ENDERECO INTEGER generated by default as identity primary KEY,
RUA VARCHAR(50),
BAIRRO VARCHAR(35),
CEP VARCHAR(10),
COMPLEMENTO VARCHAR(35),
ECOMERCIO INTEGER,
ESTADO CHAR(2)
)
I would like to change a primary key column from int to uniqueidentifier in a database project. I tried to change the type but got predictable error because SQL Server can't convert int to guid. (Original Image):
+ ------------ + -------------- + ----------- + ------- +
| Name | Data_Type | Allow Nulls | Default |
+ ------------ + -------------- + ----------- + ------- +
| OrderImageId | int | No | |
| OrderId | int | No | |
| Image | varbinary(MAX) | Yes | |
| FileName | nvarchar(Max) | Yes | |
+ ------------ + -------------- + ----------- + ------- +
create table [dbo].[OrderImages]
(
[OrderImageId] int not null primary key identity,
[OrderId] int not null
Constraint [FK_OrderImages_Orders] foreign key (OrderId) references [Orders]([OrderId]),
[Image] varbinary(Max) null,
[FileName] nvarchar(max) null
)
I know how to do it in SQL Server Management Studio (create a separate guid column, fill it, delete PK, set PK for guid column etc), but is it possible to do it in a database project? And what if my PK column has FKs?
To do this you will need to create a new table and migrate the data, substituting the guids that you want to use to replace the existing integer data.
That being said, using a uniqueidentifier here is not a good idea. It is 128 bits of essentially random data that will cause fragmentation. If you expect to have more than 4 billion images with possibly multiple images per order, you can use a bigint.
If there will be no more than one image per order, you can use the OrderID as the primary key (without the identity constraint) and avoid needing to add a nonclustered index on OrderID.
I am having following data :
Fabric Cost
time | No fabric|BangloreSilk|Chanderi|.... <- fabric types
--------------------------------------------
01/15 | 40 | 25 |...
02/15 | 45 | 30 |...
..... | ... | ... |...
Dyeing Cost
time | No fabric|BangloreSilk|Chanderi|.... <- fabric types
--------------------------------------------
01/15 | 40 | 25 |...
02/15 | 45 | 30 |...
..... | ... | ... |...
And here list of fabric types will be same for both the data.
Now to add this data I created following tables :
fabric_type
id int
fabric_type_name varchar
And then I have two approaches .
Approach 1 :
fabric_cost
id int
fabric_type_id int (foreign key to fabric_type)
cost int
deying_cost
id int
fabric_type_id int (foreign key to fabric_type)
cost int
Approach 2 :
fabric_overall_cost
id int
fabric_type_id int (foreign key to fabric_type)
cost int
fabric_or_dyeing bit (to represent 0 for fabric cost and 1 for dyeing cost)
Now the question is which approach will be better??
Maybe you can create another table - cost_subjects
cost_subjects
id byte
subject varchar
costs
id int
fabric_type_id int (foreign key to fabric_type)
cost int
cost_subject byte (foreign key to cost_subjects table)
And then you can extend the table with more subjects to include in costs of fabric
It really depends on your requirements. Are there other columns that are unique only for the fabric_cost table? Are there other columns that are unique only for the dyeing_cost table? Meaning will your 2 tables grow independently?
If yes, approach 1 is better. Otherwise, approach 2 is better because you won't need to do CRUD on 2 separate tables (for easier maintenance).
Another approach would be:
id int
fabric_type_id int (foreign key to fabric_type)
fabric_cost float/double/decimal
dyeing_cost float/double/decimal
This third approach is if you always have both costs. You might not want to use int for cost. Again, it depends on your requirements.
I have the following:
1. A table "patients" where I store patients data.
2. A table "tests" where I store data of tests done to each patient.
Now the problem comes as I have 2 types of tests "tests_1" and "tests_2"
So for each test done to particular patient I store the type and id of the type of test:
CREATE TABLE IF NOT EXISTS patients
(
id_patient INTEGER PRIMARY KEY,
name_patient VARCHAR(30) NOT NULL,
sex_patient VARCHAR(6) NOT NULL,
date_patient DATE
);
INSERT INTO patients values
(1,'Joe', 'Male' ,'2000-01-23');
INSERT INTO patients values
(2,'Marge','Female','1950-11-25');
INSERT INTO patients values
(3,'Diana','Female','1985-08-13');
INSERT INTO patients values
(4,'Laura','Female','1984-12-29');
CREATE TABLE IF NOT EXISTS tests
(
id_test INTEGER PRIMARY KEY,
id_patient INTEGER,
type_test VARCHAR(15) NOT NULL,
id_type_test INTEGER,
date_test DATE,
FOREIGN KEY (id_patient) REFERENCES patients(id_patient)
);
INSERT INTO tests values
(1,4,'test_1',10,'2004-05-29');
INSERT INTO tests values
(2,4,'test_2',45,'2005-01-29');
INSERT INTO tests values
(3,4,'test_2',55,'2006-04-12');
CREATE TABLE IF NOT EXISTS tests_1
(
id_test_1 INTEGER PRIMARY KEY,
id_patient INTEGER,
data1 REAL,
data2 REAL,
data3 REAL,
data4 REAL,
data5 REAL,
FOREIGN KEY (id_patient) REFERENCES patients(id_patient)
);
INSERT INTO tests_1 values
(10,4,100.7,1.8,10.89,20.04,5.29);
CREATE TABLE IF NOT EXISTS tests_2
(
id_test_2 INTEGER PRIMARY KEY,
id_patient INTEGER,
data1 REAL,
data2 REAL,
data3 REAL,
FOREIGN KEY (id_patient) REFERENCES patients(id_patient)
);
INSERT INTO tests_2 values
(45,4,10.07,18.9,1.8);
INSERT INTO tests_2 values
(55,4,17.6,1.8,18.89);
Now I think this approach is redundant or not to good...
So I would like to improve queries like
select * from tests WHERE id_patient=4;
select * from tests_1 WHERE id_patient=4;
select * from tests_2 WHERE id_patient=4;
Is there a better approach?
In this example I have 1 test of type tests_1 and 2 tests of type tests_2 for patient with id=4.
Here is a fiddle
Add a table testtype (id_test,name_test) and use it an FK to the id_type_test field in the tests table. Do not create seperate tables for test_1 and test_2
It depends on the requirement
For OLTP I would do something like the following
STAFF:
ID | FORENAME | SURNAME | DATE_OF_BIRTH | JOB_TITLE | ...
-------------------------------------------------------------
1 | harry | potter | 2001-01-01 | consultant | ...
2 | ron | weasley | 2001-02-01 | pathologist | ...
PATIENT:
ID | FORENAME | SURNAME | DATE_OF_BIRTH | ...
-----------------------------------------------
1 | hermiony | granger | 2013-01-01 | ...
TEST_TYPE:
ID | CATEGORY | NAME | DESCRIPTION | ...
--------------------------------------------------------
1 | haematology | abg | arterial blood gasses | ...
REQUEST:
ID | TEST_TYPE_ID | PATIENT_ID | DATE_REQUESTED | REQUESTED_BY | ...
----------------------------------------------------------------------
1 | 1 | 1 | 2013-01-02 | 1 | ...
RESULT_TYPE:
ID | TEST_TYPE_ID | NAME | UNIT | ...
---------------------------------------
1 | 1 | co2 | kPa | ...
2 | 1 | o2 | kPa | ...
RESULT:
ID | REQUEST_ID | RESULT_TYPE_ID | DATE_RESULTED | RESULTED_BY | RESULT | ...
-------------------------------------------------------------------------------
1 | 1 | 1 | 2013-01-02 | 2 | 5 | ...
2 | 1 | 2 | 2013-01-02 | 2 | 5 | ...
A concern I have with the above is with the unit of the test result, these can sometimes (not often) change. It may be better to place the unit un the result table.
Also consider breaking these into the major test categories as my understanding is they can be quite different e.g. histopathology and xrays are not resulted in the similar ways as haematology and microbiology are.
For OLAP I would combine request and result into one table adding derived columns such as REQUEST_TO_RESULT_MINS and make a single dimension from RESULT_TYPE and TEST_TYPE etc.
You can do this in a few ways. without knowing all the different type of cases you need to deal with.
The simplest would be 5 tables
Patients (like you described it)
Tests (like you described it)
TestType (like Declan_K suggested)
TestResultCode
TestResults
TestRsultCode describe each value that is stored for each test. TestResults is a pivoted table that can store any number of test-results per test,:
Create table TestResultCode
(
idTestResultCode int
, Code varchar(10)
, Description varchar(200)
, DataType int -- 1= Real, 2 = Varchar, 3 = int, etc.
);
Create Table TestResults
(
idPatent int -- FK
, idTest int -- FK
, idTestType int -- FK
, idTestResultCode int -- FK
, ResultsI real
, ResultsV varchar(100)
, Resultsb int
, Created datetime
)
so, basically you can fit the results you wanted to add into the tables "tests_1" and "tests_2" and any other tests you can think of.
The application reading this table, can load each test and all its values. Of course the application needs to know how to deal with each case, but you can store any type of test in this structure.