Hi peoples I want to create a table in apache ignite having two foreign keys(query index) in table.Below is the query.
CREATE TABLE `users_roles` (
`users_rolesId` bigint(20) unsigned NOT NULL,
`userId` bigint(20) ,
`roleId` bigint(20) ,
`createdOn` timestamp ,
`modifiedOn` timestamp,
`createdBy` bigint(20),
`modifiedBy` bigint(20),
`isActive` bit(1) ,
PRIMARY KEY (`users_rolesId`))WITH "backups=1,affinity_key=userId,affinity_key=roleId"
But it is giving me exception :
SQL Error [1001] [42000]: Duplicate parameter: affinity_key=roleId
So how to specify multiple query indexes in create statements??.
Two problems here:
Affinity key needs to be part of primary key. In your case affinity columns are not part of primary key (although they contain the same data)
You can't have more than one column as affinity key column.
Affinity determines how data is distributed between nodes. You can't have two affinities at once unless you have two different tables. You will have to choose one which is more imporant to you, and do distributed joins on the other one.
In your case, I recommend making roles table replicated and ditching affinity key on role_id.
Related
As it is said in the title, my question is can I use int identity(1,1) for primary key in more than one table in the same ER model? I found on Internet that Primary Key need to have unique value and row, for example if I set int identity (1,1) for table:
CREATE TABLE dbo.Persons
(
Personid int IDENTITY(1,1) PRIMARY KEY,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int
);
GO
and the other table
CREATE TABLE dbo.Job
(
jobID int IDENTITY(1,1) NOT NULL PRIMARY KEY,
nameJob NVARCHAR(25) NOT NULL,
Personid int FOREIGN KEY REFERENCES dbo.Persons(Personid)
);
Wouldn't Personid and jobID have the same value and because of that cause an error?
Constraints in general are defined and have a scope of one table (object) in the database. The only exception is the FOREIGN KEY which usually has a REFERENCE to another table.
The PRIMARY KEY (or any UNIQUE key) sets a constraint only on the table it is defined on and is not affecting or is not affected by other constraints on other tables.
The PRIMARY KEY defines a column or a set of columns which can be used to uniquely identify one record in one table (and none of the columns can hold NULL, UNIQUE on the other hand allows NULLs and how it is treated might differ in different database engines).
So yes, you might have the same value for PersonID and JobID, but their meaning is different. (And to select the one unique record, you will need to tell SQL Server in which table and in which column of that table you are looking for it, this is the table list and the WHERE or JOIN conditions in the query).
The query SELECT * FROM dbo.Job WHERE JobID = 1; and SELECT * FROM dbo.Person WHERE PersonID = 1; have a different meaning even when the value you are searching for is the same.
You will define the IDENTITY on the table (the table can have only one IDENTITY column). You don't need to have an IDENTITY definition on a column to have the value 1 in it, the IDENTITY just gives you an easy way to generate unique values per table.
You can share sequences across tables by using a SEQUENCE, but that will not prevent you to manually insert the same values into multiple tables.
In short, the value stored in the column is just a value, the table name, the column name and the business rules and roles will give it a meaning.
To the notion "every table needs to have a PRIMARY KEY and IDENTITY, I would like to add, that in most cases there are multiple (independent) keys in the table. Usually every entity has something what you can call business key, which is in loose terms the key what the business (humans) use to identify something. This key has very similar, but usually the same characteristics as a PRIMARY KEY with IDENTITY.
This can be a product's barcode, or the employee's ID card number, or something what is generated in another system (say HR) or a code which is assigned to a customer or partner.
These business keys are useful for humans, but not always useful for computers, but they could serve as PRIMARY KEY.
In databases we (the developers, architects) like simplicity and a business key can be very complex (in computer terms), can consist of multiple columns, and can also cause performance issues (comparing a strings is not the same as comparing numbers, comparing multiple columns is less efficient than comparing one column), but the worst, it might change over time. To resolve this, we tend to create our own technical key which then can be used by computers more easily and we have more control over it, so we use things like IDENTITYs and GUIDs and whatnot.
I have to create a database named "Elections" and then write some queries to get the answers provided by my teacher.
I created the database. My issue is that I don't know how to link two tables (candidate and constituency) because they do not share any primary or foreign key.
The teacher is saying that a composite table should not be created in order to link those two tables.
Please see picture (the tables are linked on the pictures but I do not know how to do it when I create the database).
I am also including:
the query that I have to write. The thing is, without knowing how to link those two tables, I cannot write the query.
the SQL code representing the creation of those two tables.
QUERY:
1. Display the number of candidates eliminated in the first
round, for each constituency, and show the constituency number,
and name.
SQL CODE:
CREATE TABLE CANDIDATE (
CANDIDATE_NB smallint CONSTRAINT PK_CANDIDATE_NB PRIMARY KEY NOT NULL,
PARTY_NB smallint NOT NULL,
ROUND tinyint NOT NULL
);
alter table CANDIDATE ADD CONSTRAINT FK_PARTY_NB FOREIGN KEY (PARTY_NB) REFERENCES PARTY(PARTY_NB);
CREATE TABLE CONSTITUENCY (
CONSTITUENCY_NB smallint IDENTITY (100, 100) CONSTRAINT PK_CONSTITUENCY_NB PRIMARY KEY NOT NULL,
CONSTITUENCY_NAME varchar(20) NOT NULL,
NB_REGISTERED smallint NULL,
TOTAL_CANDIDATES smallint NULL
);
I am trying to understand how to link those two tables but I really can't think of anything apart from creating a composite table, which is not what has to be done as per my teacher's instructions.
I have a table, foo, that is partitioned by 'created_at' and has its primary key as (id,created_at). I.e.:
CREATE TABLE `foo` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`created_at` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`bar_id` int(11) DEFAULT NULL,
...
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
/*!50100 PARTITION BY RANGE (TO_DAYS(created_at))
(PARTITION p0 VALUES LESS THAN (733712) ENGINE = InnoDB,
PARTITION p1 VALUES LESS THAN (733773) ENGINE = InnoDB,
PARTITION p2 VALUES LESS THAN (733832) ENGINE = InnoDB,
PARTITION p3 VALUES LESS THAN (733893) ENGINE = InnoDB,
...
)
How do I create a unique index such that bar_id is unique across all partitions? If I try something like:
CREATE UNIQUE INDEX some_index USING BTREE ON foo (bar_id);
I receive the error:
ERROR 1503 (HY000): A UNIQUE INDEX must include all columns in the table's partitioning function
But, if I include the partitioning function (id, created_at) when building the index then I end up with an index that does not guarantee that bar_id is unique.
UPDATE
I should have mentioned that I already have a primary key on the table:
PRIMARY KEY (`id`,`created_at`)
Also, bar_id can be NULL.
The error message itself explains the problem. Please, read the manual,
http://dev.mysql.com/doc/refman/5.5/en/partitioning-limitations-partitioning-keys-unique-keys.html
"The rule is : All columns used in the partitioning expression for a partitioned table must be part of every unique key that the table may have. In simple words, every unique key on the table must use every column in the table's partitioning expression."
Create a Primary Key.
From the MySQL docs on partitioning: any column used for a partitioning expression must be part of the table's primary key (if it has one) or (first) unique key (if it has a unique key but no primary key). Otherwise, you'll see the error message, "A PRIMARY KEY needs to include all fields in the partition function".
If a table has no primary key, but does have one or more unique keys, then any columns used in the partitioning expression must be part of the (first) unique key.
This can be done via a secondary table to store the unique bar_id, and a before-insert trigger.
Sorry for the newbie question.
I have define a table in a following way
CREATE TABLE `class1` (
`name` varchar(20) NOT NULL,
`familyname` varchar(20) NOT NULL,
`id` int(11) DEFAULT NULL,
KEY `class1` (`name`,`familyname`));
Can you explain me what is the difference here that i have here a name and family name as key.
I have to enter values to the table and run queries but i can't understand what it gives me ? If i not define name and family name as keys i get the same results .
A key, otherwise known as an index, will not change the results of a query, but sometimes it can make the query faster.
If you're interested, you can read about different kinds of keys here.
The KEY keyword in the create table syntax in mysql is a synonym for INDEX and will create an index on the 'name', 'familyname' columns.
This will not effect any constrains on the table but will make a query on the table faster when using the 'name' and 'familyname' columns in the where clause of a select statement.
If you wanted to create a primary key on those 2 columns you should use:
CREATE TABLE `class1` (
`name` varchar(20) NOT NULL,
`familyname` varchar(20) NOT NULL,
`id` int(11) DEFAULT NULL,
PRIMARY KEY (`name`,`familyname`));
This will stop you being able to insert multiple rows with the same 'name' and 'familyname' combination.
If you want to get data from your table, based upon the key or index fields (as said above), your query will execute faster, because the table will keep indexes about those values.
But, there is a downside to this as well. Adding unneeded indexes will have a negative effect on your performance. So to sum this all up: Indexes can speed up your database, but always check if they are really needed before adding them.
I have just managed to migrate a pretty big database from SQL Server to MySQL. I didn't set the primary keys to auto increment during the migration because the tables have relationships based on ids as primary keys which are foreign keys in another table.
Now for adding new records I want to alter the primary key 'id' columns in all tables to be autoincrement but starting from the last highest number in the id column in each table.
What's the best way to do this without losing the relationships I already have?
UPDATE: Trying to add autoincrement gives me this error:
ERROR 1067: Invalid default value for 'id'
SQL Statement:
ALTER TABLE `skandium`.`brands` CHANGE COLUMN `id` `id` INT(11) NOT NULL DEFAULT '0' AUTO_INCREMENT
ERROR 1050: Table 'brands' already exists
SQL Statement:
CREATE TABLE `brands` (
`id` int(11) NOT NULL DEFAULT '0',
`brand` varchar(50) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
Just add the auto-increment on your needed columns. It won't affect existing rows. It will start with the next available value.
Note that a column being auto-increment means just that if you don't assign a value to it one will be added by MySQL. If you want to supply explicit values you can do so without anything special happening. So you could have set those columns to auto-increment right from the start.
A column with auto-increment cannot have an explicit default value.
Tested