I'm using ormlite for Android and I'm trying to get a multiple column unique-constraint. As of now i'm only able to get a unique constraint on indiviudal columns like this:
CREATE TABLE `store_group_item` (`store_group_id` INTEGER NOT NULL UNIQUE ,
`store_item_id` INTEGER NOT NULL UNIQUE ,
`_id` INTEGER PRIMARY KEY AUTOINCREMENT );
and what I want is
CREATE TABLE `store_group_item` (`store_group_id` INTEGER NOT NULL ,
`store_item_id` INTEGER NOT NULL ,
`_id` INTEGER PRIMARY KEY AUTOINCREMENT,
UNIQUE( `store_group_id`, `store_item_id` );
In my model I've been using the following annotations for the unique columns:
#DatabaseField( unique = true )
Is there a way to get this to work?
How about using
#DatabaseField (uniqueCombo = true)
String myField;
annotation instead - is it a matter of the uniqueIndexName being faster when accessing items in the table?
Edit:
As #Ready4Android pointed out, we've since added in version 4.20 support for uniqueCombo annotation field. Here are the docs:
http://ormlite.com/docs/unique-combo
There should be no performance differences between using this mechanism versus the uniqueIndexName mentioned below.
Yes. You can't do this with the unique=true tag but you can with a unique index.
#DatabaseField(uniqueIndexName = "unique_store_group_and_item_ids")
int store_group_id;
#DatabaseField(uniqueIndexName = "unique_store_group_and_item_ids")
int store_item_id;
This will create an index to accomplish the unique-ness but I suspect that the unique=true has a hidden index anyway. See the docs:
http://ormlite.com/docs/unique-index
I will look into allowing multiple unique fields. May not be supported by all database types.
Related
everyone,
I would like an advice on best practice for creating realtional database structure with field having mixed data type.
I have 'datasets' (some business objects) and I would like to have list of parameters, associated with each dataset. And those parameters can have different types - strings, integers, float and json values.
What would be the best structure for the parameters table? Should I have single column with string type?
CREATE TABLE param_desc (
id serial PRIMARY KEY,
name varchar NOT NULL,
param_type int -- varchar, int, real, json
);
CREATE TABLE param_value (
id serial PRIMARY KEY,
dataset_id int NOT NULL,
param int NOT NULL REFERENCES param_desc (id),
value varchar NOT NULL,
CONSTRAINT _param_object_id_param_name_id_time_from_key UNIQUE (dataset_id, param)
);
The problem with such approach is that I can't easily cast value for some additional conditions. For example, I want to get all datasets with some specific integer parameter, having int value more than 10. But if I write where clause, the casting will return error, as other non-integer parameters can't be casted.
SELECT dataset_id FROM vw_param_current WHERE name = 'priority' AND value::int > 5
Or should I have 4 separate columns, with 3 of them being NULL for every row?
Or should I have 4 different tables?
I would like to do analysis of what codes appear in multiple tables under certains conditions. However I don't think the database schema suits the task very well but maybe there's something I don't know about that can help me. Here's a simplified schema:
CREATE TABLE "batchDescription" (
id INTEGER NOT NULL,
name TEXT NOT NULL UNIQUE,
PRIMARY KEY (id)
);
CREATE TABLE "simulationDetails" (
id INTEGER NOT NULL,
ko_index_id INTEGER NOT NULL,
batch_description_id INTEGER NOT NULL,
data1 REAL NOT NULL,
data2 INTEGER NOT NULL,
PRIMARY KEY (id)
FOREIGN KEY(ko_index_id) REFERENCES "koIndex" (id)
FOREIGN KEY(batch_description_id) REFERENCES "batchDescription" (id)
);
CREATE TABLE "koIndex" (
id INTEGER NOT NULL,
number_of_kos INTEGER NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE "1kos" (
ko_index_id INTEGER NOT NULL,
ko1 INTEGER NOT NULL,
PRIMARY KEY (ko_index_id)
FOREIGN KEY(ko_index_id) REFERENCES "koIndex" (id)
);
CREATE TABLE "2kos" (
ko_index_id INTEGER NOT NULL,
ko1 INTEGER NOT NULL,
ko2 INTEGER NOT NULL,
PRIMARY KEY (ko_index_id)
FOREIGN KEY(ko_index_id) REFERENCES "koIndex" (id)
);
CREATE TABLE "3kos" (
ko_index_id INTEGER NOT NULL,
ko1 INTEGER NOT NULL,
ko2 INTEGER NOT NULL,
ko3 INTEGER NOT NULL,
PRIMARY KEY (ko_index_id)
FOREIGN KEY(ko_index_id) REFERENCES "koIndex" (id)
);
This goes up to table "525kos" which has ko1 to ko525 in it - ko1 to ko525 are IDs that are primary keys in a table not shown here. I want to do an analysis of how often certain IDs are present under certain conditions. Here is a simple example to illustrate:
I would like to like to count the amount of times a certain ID (let's say 127) (in any koX column) in the "13kos" table occurs when simulationDetails.data1 not equal to 0. I would do this on a database called ko.db from the bash command line like:
for ko_idx in {1..13}; do sqlite3 ko.db "select count(ko${ko_idx}) from '13kos' where ko${ko_idx} = 127 and ko_index_id in (select ko_index_id from simulationDetails where data1 != 0);"; done
Already this is slow and inefficient but is simple compared to what I would like to do. What if I wanted to do an analysis of all the IDs in all possible columns in all "Xkos" tables and compare them to where data1 is equal and not equal to zero?
Can anybody direct me to a better way of doing this or is the schema design just not very good for this kind of analysis and I'll have to give up?
EDIT: Thought I'd add a bit of extra detailto avoid confusion. I suspect that a good way to achieve want I want would be to somehow combine all the "Xkos" tables into one temporary table and then search for certain IDs from that table. How would I combine all 525 ko tables without writing out each table name?
How would I combine all 525 ko tables without writing out each table
name?
Create a table with the same number of columns as the largest table (the table into which you merge) allowing nulls.
query the sqlite_master table using something like :-
SELECT * from sqlite_master WHERE name LIKE '%kos%' AND type = 'table'
Loop through the extracted table names building an INSERT SELECT for each table that will insert the rows from the tables into the table created in 1.
See 2. INSERT INTO table SELECT ...; especially in regard to handling missing columns.
All done, the table created in 1 will be populated accordingly.
I have table with chromosomes (objects that have length) and table with regions (for example genes) on the chromosomes (objects that have range defined as two integers - position start and position end). I would like to forbid inserting into database regions with coordinates greater than length of particular chromosome.
Is it possible in SQLite?
If not is it possible in any other SQL system (preferably free)?
DROP TABLE IF EXISTS chromosomes;
CREATE TABLE chromosomes
(
chromosome_id INTEGER UNIQUE NOT NULL CHECK(TYPEOF(chromosome_id) = 'integer'),
name VARCHAR UNIQUE NOT NULL CHECK(TYPEOF(name) = 'text'),
length INTEGER NOT NULL CHECK(TYPEOF(length) = 'integer' AND length > 0),
PRIMARY KEY (chromosome_id)
);
DROP TABLE IF EXISTS genes;
CREATE TABLE genes
(
gene_id INTEGER UNIQUE NOT NULL CHECK(TYPEOF(gene_id) = 'integer'),
symbol VARCHAR NOT NULL CHECK(TYPEOF(symbol) = 'text'),
refseq_id VARCHAR NOT NULL CHECK(TYPEOF(refseq_id) = 'text'),
chromosome_id INTEGER NOT NULL CHECK(TYPEOF(chromosome_id) = 'integer'),
start INTEGER NOT NULL CHECK(TYPEOF(start) = 'integer' AND start > 0 AND start < end),
end INTEGER NOT NULL CHECK(TYPEOF(end) = 'integer' AND end > 0 AND end > start),
external_db_link VARCHAR NOT NULL CHECK(TYPEOF(external_db_link) = 'text'),
PRIMARY KEY (gene_id)
FOREIGN KEY (chromosome_id) REFERENCES chromosomes(chromosome_id)
);
This type of constraint is not easily available in any database. In general, this would be handled using a trigger. The problem is that it is a constraint between two tables, but it does not use equality.
Triggers are available in SQLite as well as other databases.
One work-around is a check constraint using a user-defined function. The function can do the lookup into the chromosomes table and be used in a check constraint. SQLite doesn't really have user-defined functions. One database that supports this is Postgres.
Another option is to wrap all data modifications in stored procedures (this tends to be the way that I design systems). Then the stored procedure can do all the checks that are needed.
Redundantly - bring 'length' into the child table using a foreign key.
Then your Check Constraint can reference that.
I have just started with SQL and want to clear the basic keywords of SQL.
What is the difference between
"number" and "numeric" & "number & integer"?
While creating a table
Create table myTable
(
my_Id int(6) primary key
...
Above query Gives me an error suggesting to put null or not null before "primary key".
Do I always need to put either null or not null for the keyword integer?
If I replace int(6) with number(6), that statement works.
1."number" and "numeric" & "number & integer"?
An integer cannot take inputs such as 1.1 and the likes since float or decimal datatype handles this, while a number can take this both. I believe the reason why INT does not display it with a decimal its because its being rounded off try to input a 1.5 on an int column and you'll get a 2 instead
2.While creating a table
Create table myTable (
my_Id int(6) primary key, <--- Gives me an error suggesting to put
null or not null before "primary key". Do I always need to put either
null or not null for the keyword integer?
you need to either put a null or not null before a primary key unless I believe its been set into an Auto Increment
BTW my answer was based on MYSQL since that's what I used.. although I'm not sure if your using it since you didn't add any tags :)
for more info for this topic I think this could add a little more light to your inquiry
reference link
In MYSQL a primary key has to be a non-null value ie you will have to indicate by typing in NOT NULL You can re-write the code as follows:
my_id INT([optional]) PRIMARY KEY NOT NULL
When you want to make a Primary Key field it shouldn't be Null.
And
When you use int data type it don't have any (<value>), But number has.
SO
my_Id int not null primary key
I am fairly new to SQL but have been working hard to learn. I am currently stuck on an issue with setting a primary key to have 8 digits no matter what.
I tried using INT(8) but that didn't work. Also AUTO_INCREMENT doesn't work in PostgreSQL but I saw there were a couple of data types that auto increment but I still have the issue of the keys not being long enough.
Basically I want to have numbers represent User IDs, starting at 10000000 and moving up. 00000001 and up would work too, it doesn't matter to me.
I saw an answer that was close to this, but it didn't apply to PostgreSQL unfortunately.
Hopefully my question makes sense, if not I'll try to clarify.
My code (which I am using from a website to try and make my own forum for a practice project) is:
CREATE Table users (
user_id INT(8) NOT NULL AUTO_INCREMENT,
user_name VARCHAR(30) NOT NULL,
user_pass VARCHAR(255) NOT NULL,
user_email VARCHAR(255) NOT NULL,
user_date DATETIME NOT NULL,
user_level INT(8) NOT NULL,
UNIQUE INDEX user_name_unique (user_name),
PRIMARY KEY (user_id)
) TYPE=INNODB;
It doesn't work in PostgreSQL (9.4 Windows x64 version). What do I do?
You are mixing two aspects:
the data type allowing certain values for your PK column
the format you chose for display
AUTO_INCREMENT is a non-standard concept of MySQL, SQL Server uses IDENTITY(1,1), etc.
Use a serial column in Postgres:
CREATE TABLE users (
user_id serial PRIMARY KEY
, ...
)
That's a pseudo-type implemented as integer data type with a column default drawing from an attached SEQUENCE. integer is easily big enough for your case (-2147483648 to +2147483647).
If you really need to enforce numbers with a maximum of 8 decimal digits, add a CHECK constraint:
CONSTRAINT id_max_8_digits CHECK (user_id BETWEEN 0 AND < 99999999)
To display the number in any fashion you desire - 0-padded to 8 digits, for your case, use to_char():
SELECT to_char(user_id, '00000000') AS user_id_8digit
FROM users;
That's very fast. Note that the output is text now, not integer.
SQL Fiddle.
A couple of other things are MySQL-specific in your code:
int(8): use int.
datetime: use timestamp.
TYPE=INNODB: just drop that.
You could make user_id a serial type column and set the seed of this sequence to 10000000.
Why?
int(8) in mysql doesn't actually only store 8 digits, it only displays 8 digits
Postgres supports check constraints. You could use something like this:
create table foo (
bar_id int primary key check ( 9999999 < bar_id and bar_id < 100000000 )
);
If this is for numbering important documents like invoices that shouldn't have gaps, then you shouldn't be using sequences / auto_increment