I have a requirement where I need to uniquely identify a row based on two columns.
nType | dType | severity
------+-------+----------
down | 6500 | CRITICAL
Combination of nType and dType should always be unique. So, I created a table using
CREATE TABLE IF NOT EXISTS severitymapping(nType text, dType text, severity text,
PRIMARY KEY (nType, dType);
But there can be a case when dType is empty. So, that too is unique for my business logic. But database will not allow empty/null value of dType in the database.
Is there a way to achieve this?
For MySQL only (the question is MySQL-tagged).
Primary key expression cannot include NULLable columns.
If you need some column value to be NULL (not "empty" - there is no such term in SQL) then you cannot create PRIMARY key which includes this column. But you may create UNIQUE index - it allows NULLs. In this case you need in another expression to be primary key - autoincremented synthetic PK is reasonable.
Also the datatype for each column must be reasonable - the values shown and TEXT datatype does not match this. VARCHAR for nType and INT for dType looks like more suitable.
And TEXT column cannot be used in the index without the indexed prefix length specified.
So use something close to
CREATE TABLE IF NOT EXISTS severitymapping(
nType VARCHAR(255),
dType INT,
severity TEXT,
UNIQUE (nType, dType),
id INT AUTO_INCREMENT PRIMARY KEY
);
It isn't possible to have a null or empty value for any of the columns in a primary key in Cassandra.
The partition key (nType) uniquely identifies the partition and its hash value determines the node on which it is stored.
The clustering key (dType) uniquely identifies a row within a partition. Without it, it is not possible to store the row in the partition because the row cannot be retrieved without the clustering key. Cheers!
In your case, you are keeping nType as the partition key and dType as the clustering key.
Cassandra does not allow null clustering key values.
If you really need "no value" for some reason, then use an empty string OR some other special literal value like 'UNDEFINED' to cluster those together.
This question can help you too.
Related
How can I insert new data in column after adding column without using update function. for example
"alter table Employee add column Gender varchar(1) after Birthdate then I get wrong when I used this statement insert into Employee(ENumber,EmpName,Birthdate,Address,Salary,DNumber,Gender)
-> values
-> ('E001','GSInocencio','1988-01-15','Munoz',18000,'D005','F'),
It gives me error Duplicate entry 'E001' for key 'PRIMARY'
MariaDB [Employees_Valdez]>
The messages is pretty clear: You already have an employee with that ENumber value.
You have a UNIQUE constraint on that column, it's a PRIMARY KEY, so either pick a different value, or use a different primary key.
One thing to note is MySQL doesn't use complex string primary keys very efficiently, they're also a real hassle for relating data since they're so big. It's usually better to include a standard id INT AUTO_INCREMENT PRIMARY KEY column and then have things like ENumber being a secondary UNIQUE constraint.
You can then relate data using the 4-byte id value, or 8-byte if BIGINT is a concern like you might have two billion employees.
I tried to add primary key in a table and set it as a column that has default value and is not null and is not unique.MySQL accepted that column as Primary Key...I want to know that this is wrong as if a user enters 2 records having default values he will not be able to do so..Is this a problem where SQL should have checked column as non default values or this is a designer end problem that default columns should not be made Primary Key...?
I'm not fully understanding the problem. You have declared a column to be a primary key that has these characteristics:
NOT NULL
Default value
A primary key imposes these characteristics:
NOT NULL
Unique
These characteristics are not mutually incompatible. The only issue is that the default value can only be assigned once in the column. The second time you try to insert a row with the default value, you will get a violation of the uniqueness constraint.
In other words, MySQL (and I think other databases as well) allow you declare this even if it doesn't seem like a good idea.
Null:
every column that is flagged wiht NULL is just specified that this column may contain a NULL value. The column can still have another default value.
Primary key:
A PK is always treated unique and you cannot have two identical values on a row
There can only be one PK per table, its the main index which is very fast when querying the table on its primary column.
A PK is always a single column and cannot be spread over multiple columns as every other index (unique or usual index) can do.
A PK column cannot accept NULL values
Sample:
ID (INT, PK) | Name (varchar)
1 | Foo ->Valid
2 | Bar ->Valid
2 | FooBar ->Invalid (Duplicate Primary key value ID)
Conclusion: Yes MySQL should and will throw an error at second attempt to put a default value because its simply treated UNIQUE and a given default value is const. The MySQL server will attempt to insert the default value when you dont specify any value for this column in your insert statement.
Pretty much means: A PrimaryKey column with a default value makes no sense, except you use an auto-increment which is a pseudo "default value" which is different each time you try to insert something.
I hope this answers your questions
i faced an interview question yesterday regarding sql table design.
the question is if the table contains fields like firstName,lastName,Gender(only these fields not not any more)which one we can select as a primary key?
any hint will greatly appreciated
Thank you
None of them will be unique within the table, so you need to make an extra primary key field that auto-increments so that it will be guaranteed never to be the same for two rows. Sounds like they got you with a trick question :)
A PRIMARY KEY must be unique. So you must construct it from data which will not repeat.
So primary key is a unique & not null value.
if the table contains fields like firstName,lastName,Gender(only these fields not not any more)which one we can select as a primary key.
there is you can not use above column as a primary key.
You can combine one field with another field that will give you a primary key (not very recommendable, but you can make this field plus a timestamp field your combined primary key).....
Here's my 2 cents (these rules applies for every new table, for the beginner schema designers)
the primary key should not be compound (that is, it should contain only 1 column)
the primary key column should contain no meaningful data (it should be a number generated and assigned automatically to the new record)
the value of primary key should never change, and should not be null
besides the primary key, you should have an other unique key, probably a compound key, using the meaningful data fields, just to make sure you do not have duplicate records (e.g. firstName,lastName,dateOfBirth)
I want a table with an integer column, that may or may not be filled (it is a social security number). But if it is filled, I want it to be UNIQUE : there cannot be two entries of the same number.
Using a unique constraint won't work cause integer won't accept NULL values, and MySQL detects multiple 0 values.
How can I set a unique constraint on an integer with a default value ? Or how can I set the integer column to accept NULL values ? (this question takes it for granted : MySQL Foreign Key Constraint - Integer Column but I can't)
create table test (
myint INT NULL, UNIQUE INDEX (myint)
);
This will allow a unique constraint on any integers added but will allow multiple NULL values to be entered.
MySQL treats NULL as 'unknown' value so cant possibly do a comparison to see if a like value is already there 'unknown' !== 'unknown'.
This also depends on which database engine you are using, the above holds true for MyISAM and InnoDB
Please see the code below:
ALTER TABLE test MODIFY myint INT NULL
ALTER TABLE test ADD UNIQUE INDEX (myint)
It works when data inputs are directly from MySQL (PHPMyadmin), saved as NULL, but a php script saves it as zeroes, and so it does not allow multiple entries.
It is my understanding that when I make a table without a primary key that MySQL creates a sort of underlying primary key that it uses internally.
I am working with a table that does not have a primary key, but it would be very useful for my application if I could somehow access this value, assuming it does in fact exist and is retrievable.
So, I am wanting to know if I am correct in believing that such a value exists somewhere and also if it is possible to get that value.
Edit: just to make it clear, it would be very useful for my application for this table to have an incrementing int attribute. Unfortunately, it was not implemented that way. So, I am sort of grasping at straws to find a solution. What I am trying to do is select every nth row in the table (n changes). So, as you can see if there was this key, this would be very simple.
If a table has no primary key then there's no way of specifying a specific row within it because there is no way to uniquely identify an item. Even if you use a query that specifies a specific value for every column that still wouldn't be certain to only return a single row as without a primary key there's nothing to prevent duplicate rows.
However, a primary key is simply a unique index. If a table has a unique index on one or more of its columns and those columns don't accept NULLs then this is the primary key for the table in all but name.
If you table has no unique columns then you've got nothing to go on. You'll have to either make one column or combination of columns (for a composite key) unique, or add a column that serves as the primary key for the table. Fortunately it's relatively easy to add columns to a MySQL table, just add a primary key autoincrement column to the existing table.