I created table in Cassandra database name as information_tbl.
query:
CREATE TABLE IF NOT EXISTS Information_tbl (id uuid ,
cam_id varchar,
camzone varchar,
msg varchar,
fltr int,
time_stamp int,
PRIMARY KEY (fltr,time_stamp)
)WITH CLUSTERING ORDER BY (time_stamp DESC);
when I execute update query, it show error :
Query 1:
UPDATE information_tbl SET camzone = 'D' WHERE id = c6263cac-450f-4105-a2cc-3705ec741a96;
Error:
message="Some partition key parts are missing: fltr"
Query 2:
UPDATE information_tbl SET camzone = 'D' WHERE fltr=1 AND id = c6263cac-450f-4105-a2cc-3705ec741a96;
Error:
message="Some clustering keys are missing: time_stamp"
Query 3:
UPDATE information_tbl SET camzone = 'D' WHERE fltr=1 AND time_stamp = 1581946832 AND id = c6263cac-450f-4105-a2cc-3705ec741a96;
Error:
message="Non PRIMARY KEY columns found in where clause: id "
Any suggestions.
In the 3 queries provided, you are treating the column id as if it was part of the primary key; here is a succinct explanation of their characteristic. You may also visit the data model explanations in DS201 of DataStax Academy.
From the query example 2, it looks that fltr may have a low cardinality, which will also be troublesome, please refer to this explanation.
To update Cassandra row in Cassandra, you need Partition Key + Clustering Key. Coming to you error messages
Error 1 : message="Some partition key parts are missing: fltr" in this case you are not passing any partition key columns.
Error 2 : message="Some clustering keys are missing: time_stamp" in this case you are passing a part of partition key columns.
Error 3 : message="Non PRIMARY KEY columns found in where clause: id " in this case you are passing partition key columns along with other columns.
If you have the value of ID available, you can change your data model as below to perform an update.
CREATE TABLE IF NOT EXISTS Information_tbl (id uuid ,
cam_id varchar,
camzone varchar,
msg varchar,
fltr int,
time_stamp int,
PRIMARY KEY (id, fltr,time_stamp)
)WITH CLUSTERING ORDER BY (time_stamp DESC);
If you want to update table fields you must need primary key in where clouse for that.
If you do not have it first get it(primary key field value) using select query(you can use select query without primary key) and then use update query on the basis of that primary key.
Related
I am trying to create a SQL table to store a customer id and zipcode, only these 2 columns. Combination of these 2 values makes a row unique. I have 3 options in mind but not sure which one would be efficient. I will store around 200000 rows in this table and the read operation is high and write will happen once in a day.
Select query will get all customers based on the input zipcode.
example:
Select customerid from dbo.customerzipcode where zipcode in (<multiple zipcodes>)
Option 1:
Create a table with 2 columns (customerid and zipcode)
Create a composite primary key for these 2 columns.
Option 2:
Create a table with 3 columns (id, customerid and zipcode)
id being identity and primary key
create a unique constraint for customerid and zipcode
Option 3:
Create a table with 3 columns (id, customerid and zipcode)
Create a non clustered index for zipcode alone.
Can you please share which option would be better?
Select customerid from dbo.customerzipcode where zipcode in ()
The canonical design would have an index with each column as the leading column to support efficient lookup by zipcode or by customerid, eg
create table customerzipcode
(
zipcode varchar(10) not null,
customerid int not null references customer,
constraint pk_customerzipcode primary key (zipcode,customerid),
index ix_customerzip_customerid (customerid)
)
I have a table with columns id, name, created_at and severity and the table can end up having milions of records.
I am considering to apply indexing on created_at and severity as that is what I am filtering by on UI.
I also need to have composite primary key set on id and created_at
PRIMARY KEY, btree (created_at, id) [Due to some 3rd party tool requirements]
With the above primary key setup do I just need to add a simple index on severity (as created_at is already indexed) or should I create a composite index on [created_at, severity]
According to the docs, if you are going to be filtering on those two fields together, then it's advised that you should do a multicolumn index.
As shown in the docs, if you have a table:
CREATE TABLE test2 (
major int,
minor int,
name varchar
);
and query often with:
SELECT name FROM test2 WHERE major = constant AND minor = constant;
then it's a good idea to index like:
CREATE INDEX test2_mm_idx ON test2 (major, minor);
I have a DB table :
CREATE CACHED TABLE LOGIN(ROWNO INTEGER GENERATED BY DEFAULT AS
IDENTITY(START WITH 1,INCREMENT BY 1),USERID VARBINARY(128) PRIMARY
KEY,LOGINA VARBINARY(128));
And a insert query :
prepareStatement = conn.prepareStatement(" INSERT INTO LOGIN
(USERID,LOGINA) VALUES(?,?)”)
preparedStatement.setBytes(1,someBytes);
preparedStatement.setBytes(2,someOtherBytes);
preparedStatement.executeUpdate();
The table rows insertion is strange :
RowNo UserID LoginA
1 3 data3 data3
2 2 data2 data2
3 1 data1 data1
when a button clicked, a one new row inserted ..As you see RowNo 1 should be on top of the list rather than the last cuz it was the first inserted...each new inserted row comes at the top of the table ...any idea why and how to solve ?
ok I found the reason ; basically I wanted the UserID to be a Primary Key to use as Foreign Key in other table ; here is the options :
1- RowNo not primary key ,UserID Primary Key : you get the strange table rows .
2- RowNo not primary key, UserId Unique : you get strange table rows .
3- RowNo Primary Key , UserID Unique ....this will give you the correct table with rows numbers start with 1 downward. And since Unique key column can be used as Foreign Key, then all things good :)
In a relational database, you should not expect the rows to be returned in a particular order without adding an ORDER BY clause to a SELECT statement. Your results are ordered on the PK column because HSQLDB uses the primary key index to return the results in this case. When there is an ORDER BY, it is guaranteed the rows are ordered regardless of the database software used, or the actual SELECT statement.
I am creating a table Brands with the following schema :
UserId
CarId
Brand
The UserId references the id of an user in the user table
The CarId references the id of a car in the car table
The only query that I will use is a search bases on these 2 columns, to get the corresponding brand.
So my question was about the constraint part, as I am a beginner, I would like to know which type of constraint to use (index, primary key, clustered or non clustered, on each field or on the 2 fields together) to have my query the more optimized possible.
This is my script right now :
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Brands]') AND type in (N'U'))
BEGIN
CREATE TABLE [Brands]
(
UserId BIGINT NOT NULL
CONSTRAINT [FK_Brands_Users]
FOREIGN KEY REFERENCES [Users] (UserId),
CarId BIGINT NOT NULL
CONSTRAINT [FK_Brands_Cars]
FOREIGN KEY REFERENCES [Cars] (CarId),
Brand nvarchar(15),
);
END
GO
ALTER TABLE [Brands]
ADD CONSTRAINT [Unique_UserId_BrandId] UNIQUE(UserId, BrandId);
GO
I would create a primary key including both fields. When you define a primary key it automatically create a clustered index. Also your primary key has a unique constraint build in. Your table is now a heap the way you wrote it here above which is not good. You can additionally create an extra non-clustered index on CarId. Having an additional non-clustered index on UserId is not usefull I think. The column UserId can use the clustered index because it's the first field in the clustered index but I'm not sure about that.
I am listing all FK constraints for a given table using INFORMATION_SCHEMA set of views with the following query:
SELECT X.UNIQUE_CONSTRAINT_NAME,
"C".*, "X".*
FROM "INFORMATION_SCHEMA"."KEY_COLUMN_USAGE" AS "C"
INNER JOIN "INFORMATION_SCHEMA"."REFERENTIAL_CONSTRAINTS" AS "X"
ON "C"."CONSTRAINT_NAME" = "X"."CONSTRAINT_NAME"
AND "C"."TABLE_NAME" = 'MY_TABLE'
AND "C"."TABLE_SCHEMA" = 'MY_SCHEMA'
Everything works perfectly well, but for one particular constraint the value of UNIQUE_CONSTRAINT_NAME column is wrong, and I need it in order to find additional information from the referenced Column. Basically, for most of the rows the UNIQUE_CONSTRAINT_NAME contains the name of the unique constraint (or PK) in the referenced table, but for one particular FK it is the name of some other unique constraint.
I dropped and re-created the FK - did not help.
My assumption is that the meta-data is somehow screwed. Is there a way to rebuild the meta data so that the INFORMATION_SCHEMA views would actually show the correct data?
edit-1: sample db structure
CREATE TABLE MY_PARENT_TABLE (
ID INTEGER,
NAME VARCHAR,
--//...
CONSTRAINT MY_PARENT_TABLE_PK PRIMARY KEY CLUSTERED (ID)
)
CREATE UNIQUE NONCLUSTERED INDEX MY_PARENT_TABLE_u_nci_ID_LongName ON MY_PARENT_TABLE (ID ASC) INCLUDE (SOME_OTHER_COLUMN)
CREATE TABLE MY_CHILD_TABLE (
ID INTEGER,
PID INTEGER,
NAME VARCHAR,
CONSTRAINT MY_CHILD_TABLE_PK PRIMARY KEY CLUSTERED (ID)
,CONSTRAINT MY_CHILD_TABLE__MY_PARENT_TABLE__FK
FOREIGN KEY (PID)
REFERENCES MY_PARENT_TABLE (ID)
ON UPDATE NO ACTION
ON DELETE NO ACTION
)
I expect the UNIQUE_CONSTRAINT_NAME to be MY_PARENT_TABLE_PK, but what I am
getting is MY_PARENT_TABLE_u_nci_ID_LongName.
Having looked at the structure, I see that in fact there are 2 UNIQUE constaints on that column - PK and the MY_PARENT_TABLE_u_nci_ID_LongName. So the real question should probably be: why does it take some other unique index and not the PK?
Since you have both a PK and a UNIQUE constraint on the same column, SQL Server picks one to use. I don't know if it picks the UNIQUE constraint because it is thinner (i.e. fewer columns involved) and might require fewer reads to confirm matches(?)
I don't see any way within SQL to enforce which one it chooses, other than ordering your scripts - create the table with the PK, create the other table and the FK, then create the UNIQUE constraint if you really need it - but is that really the case?