I have written an application in Javascript which inserts data into two tables via a connection to a MariaDB server.
There should be a 1:1 correspondance between the rows in these tables when first running the application.
One table stores (simulated) data about properties, the other table stores data about prices. There should be 1 price for each property. At a later date, the price might change, so there could be more than one entry for the price, but this cannot happen when the application is first run. These entries also cannot be in violation of a unique index - but they are.
Perhaps I have misconfigured something in MariaDB? Here is the code which generates the tables.
drop table if exists property_price;
drop table if exists property;
create table property
(
unique_id bigint unsigned not null auto_increment primary key,
web_id bigint unsigned not null,
url varchar(256),
street_address varchar(256),
address_country varchar(64),
property_type varchar(64),
num_bedrooms int,
num_bathrooms int,
created_datetime datetime not null,
modified_datetime datetime not null
);
create table property_price
(
property_unique_id bigint unsigned not null,
price_value decimal(19,2) not null,
price_currency varchar(64) not null,
price_qualifier varchar(64),
added_reduced_ind varchar(64),
added_reduced_date date,
created_datetime datetime not null
);
alter table property_price
add constraint fk_property_unique_id foreign key(property_unique_id)
references property(unique_id);
alter table property
add constraint ui_property_web_id
unique (web_id);
alter table property
add constraint ui_url
unique (url);
alter table property_price
add constraint ui_property_price
unique (property_unique_id, price_value, price_currency, price_qualifier, added_reduced_ind, added_reduced_date);
Below is a screenshot from DBeaver showing that a select statement returns two identical rows.
I don't understand why the unique constraint appears to be violated. The constraint does sometimes work, because if I run my application again, it fails because it attempts to insert a duplicate row which already exists in the DB. (Not the same as the one shown below.)
Can anyone point me in the right direction as to how I might debug this?
MariaDB permits multiple values on columns which form part of a unique constraint.
My solution would be to put the logic for checking for duplicate rows into the application, rather than this being on the database side. Essentially this means the unique constraint is not being used.
Related
What is better for multiply clients?
I create training project and can't understand what's better. Create one big stock portfolio table for all broker's clients or create individual table for each client? Individual table will require add brokerage agreement id for each table's name for it indentification.
DROP TABLE IF EXISTS portfolio;
CREATE TABLE common_portfolio (
common_portfolio_id serial,
brokerage_agreement_id BIGINT UNSIGNED NOT NULL,
type_assets_id BIGINT UNSIGNED NOT NULL,
stock_id BIGINT UNSIGNED NOT NULL,
stock_num BIGINT UNSIGNED NOT NULL,
FOREIGN KEY (brokerage_agreement_id) REFERENCES brokerage_agreement (brokerage_agreement_id),
FOREIGN KEY (type_assets_id) REFERENCES type_assets (type_assets_id),
FOREIGN KEY (stock_id) REFERENCES stock (stock_id)
);
VS
DROP TABLE IF EXISTS portfolio_12345612348; -- number generate from brokerage_agreement_id
CREATE TABLE portfolio_12345612348 (
position_id serial,
type_assets_id BIGINT UNSIGNED NOT NULL,
stock_id BIGINT UNSIGNED NOT NULL,
stock_num BIGINT UNSIGNED NOT NULL,
FOREIGN KEY (type_assets_id) REFERENCES type_assets (type_assets_id),
FOREIGN KEY (stock_id) REFERENCES stock (stock_id)
);
It is always better to keep all them in same table.
Keeping each client's data in a separate table will provide you with best performance only in case when you're looking for this particular customer.
But in all other cases it will be hell: creating/deleting a client will require you to build a dynamical create/drop table statement.
When sometime later you decided to add a column, you'll need to find ALL of those tables somehow and add new column to each one of them.
Even counting number of clients will cause you to write way more code rather than just "select count" statement.
And many more cases
So, use only one table
I have a main table called results. E.g.
CREATE TABLE results (
r_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
r_date DATE NOT NULL,
system_id INT NOT NULL,
FOREIGN KEY (system_id) REFERENCES systems(s_id) ON UPDATE CASCADE ON DELETE CASCADE
);
The systems table as:
CREATE TABLE systems (
s_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
system_name VARCHAR(50) NOT NULL UNIQUE
);
I'm writing a program in Python with MySQL connector. Is there a way to add data to the systems table and then auto assign the generated s_id to the results table?
I know I could INSERT into systems, then do another call to that table to see what the ID is for the s_name, to add to the results table but I thought there might be quirk in SQL that I'm not aware of to make life easier with less calls to the DB?
You could do what you describe in a trigger like this:
CREATE TRIGGER t AFTER INSERT ON systems
FOR EACH ROW
INSERT INTO results SET r_date = NOW(), system_id = NEW.s_id;
This is possible only because the columns of your results table are easy to fill in from the data the trigger has access to. The auto-increment fills itself in, and no additional columns need to be filled in. If you had more columns in the results table, this would be harder.
You should read more about triggers:
https://dev.mysql.com/doc/refman/8.0/en/create-trigger.html
https://dev.mysql.com/doc/refman/8.0/en/triggers.html
When I use this query:
CREATE TABLE users(
id int not null auto_increment primary key,
username varchar(30) not null unique,
email varchar(255) not null unique,
password varchar(255) not null
);
CREATE TABLE items(
id int not null auto_increment primary key,
name varchar(30) not null,
user_id int not null,
FOREIGN KEY user_key(user_id)
REFERENCES users(id)
);
DROP TABLE users;
It shows this error:
1217 - Cannot delete or update a parent row: a foreign key constraint fails
Which is alright because that is how mySQL database naturally reacts when we want to drop table that is referenced by other table that depends on it.
However, this same query shows no errors and actually drops users table on my pal's PC.
What could be the case? Is there a way to disable it?
You may be using different database engines. MyISAM and InnoDB have different FK support/enforcement, I believe. It could also be that the data in each of your tables is different.
If you want to drop a table that is a dependency of another table, though, the "right" way is to remove the FK from the dependent table and then drop the table that you want to.
I have the following table that will store a file (image, PDF, etc.)
CREATE TABLE `tbl_file` (
`id` INT(10),
`size` FLOAT,
`name` VARCHAR(45),
`type` VARCHAR(16),
`content` BLOB,
`date_time` TIMESTAMP,
PRIMARY KEY (`id`)
)
There are many tables that will have files (tbl_order & tbl_payment) and I want to use only one table to store files (tbl_file). However, some tables may have multiple files for each row.
For example, there are multiple files for one order (invoice, PO, BL, contract) and there may be multiple files for each payment, etc.
So I made the following junction tables for each table that may have multiple files ( I didn't include the foreign key code).
CREATE TABLE `tbl_order_file` (
`order_id` INT(10),
`file_id` INT(10),
PRIMARY KEY (`order_id`, `file_id`),
)
and
CREATE TABLE `tbl_payment_file` (
`payment_id` INT(10),
`file_id` INT(10),
PRIMARY KEY (`payment_id`, `file_id`),
)
the problem here, is that one file can be related to both tables. Maybe it's an advantage rather than a problem but I would like to know if there is a better way to do this or to find a way to restrict the file so it's only referenced in one table.
I am using MySQL with innodb engine.
One way to declare constraint to enforce this for you is to make sure each row in tbl_file is marked as the type of file, either 'O' or 'P' (or other types in the future).
CREATE TABLE `tbl_file` (
`id` INT(10),
`file_type` CHAR(1) NOT NULL, -- must be 'O' or 'P'
`size` FLOAT,
`name` VARCHAR(45),
`type` VARCHAR(16),
`content` BLOB,
`date_time` TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY (`id`, `file_type`)
);
Then each subordinate table forces all its rows to be marked with the respective type. Therefore a row in tbl_order_file can reference only rows in tbl_file that have the same file_type:
CREATE TABLE `tbl_order_file` (
`order_id` INT(10),
`file_id` INT(10),
`file_type` CHAR(1) NOT NULL, -- must be 'O'
PRIMARY KEY (`order_id`, `file_id`),
FOREIGN KEY (`file_id`, `file_type`) REFERENCES `tbl_file` (`id`, `file_type`)
);
And likewise for tbl_payment_file:
CREATE TABLE `tbl_payment_file` (
`payment_id` INT(10),
`file_id` INT(10),
`file_type` CHAR(1) NOT NULL, -- must be 'P'
PRIMARY KEY (`payment_id`, `file_id`),
FOREIGN KEY (`file_id`, `file_type`) REFERENCES `tbl_file` (`id`, `file_type`)
);
One difficulty in MySQL particularly is that MySQL doesn't support CHECK constraints to allow the table definitions to restrict the value of file_type. You'd have to do it in a trigger or with application code.
Re your comment:
Let's say I want to go with my solution without having file_type, what would be an issue in the future?
Well, as you already stated in your original question, without some constraint, there's nothing preventing one row in the file table from being referenced by multiple junction tables, and you could end up with data that is an anomaly for your application.
On the other hand, you might want to allow that flexibility, if a given file pertains to both an order and a payment. If you had no ability to maintain the multiple references, you'd then have to make duplicate copies of such files to allow them to be in multiple categories.
One more issue: none of these solutions prevents your app from inserting a row in the file table that is childless; i.e. a file that has no references from any junction table.
First of all: if you have many-to-one relations between tables, then don't create a primary key on order_id.
I would put all files into one table (tbl_file) and add two foreign key fields to the table: order_id and payment_id, which would reference to the respective entry in the payment or order table.
So an entries (in case of one payment having more then one file) would look like:
id payment_id order_id size name type content date_time
1 1 null 434 File.txt text/plain <blob> 24.11.2012
2 1 null 131 File2.txt text/plain <blob> 24.11.2012
I am not sure how to phrase the question so I'll illustrate the tables and the explain what I want to achieve.
-- static table of the entity classes supported by the application
create table entity_type (
id integer not null auto_increment,
name varchar(30) not null,
primary key(id)
);
-- static table of statuses supported by the application
create table entity_status (
id integer not null auto_increment,
name varchar(30) not null,
primary key(id)
);
-- table of valid combinations
create table entity_type_entity_status_link (
entity_type_id integer not null,
entity_status_id integer not null,
unique key(entity_type_id, entity_status_id),
foreign key(entity_type_id) references entity_type(id),
foreign key(entity_status_id) references entity_status(id),
);
-- The tables where user types and statuses are defined
create table user_type (
id integer not null auto_increment,
name varchar(30) not null,
entity_type_id integer not null,
primary key(id),
foreign key(entity_type_id) references entity_type(id)
);
create table user_status (
id integer not null auto_increment,
name varchar(30) not null,
entity_status_id integer not null,
primary key(id),
foreign key(entity_status_id) references entity_status(id)
);
-- table of valid pairs
create table user_type_user_status_link (
user_type_id integer not null,
user_status_id integer not null,
unique key(user_type_id, user_status_id),
foreign key(user_type_id) references user_type(id),
foreign key(user_status_id) references user_status(id),
);
The basic premise behind these tables is that the system supports core types and statuses and the user is able to create their own user types and statues that derive from these.
The question I have is that I cannot see a way of creating any database constraints on the user_type_user_status_link table to ensure that the you cannot insert a file_type - file_status pair where the parent entity_type - entity_status is itself not valid. Or is this something that would have to be done with triggers.
The basic premise behind these tables is that the system supports core
types and statuses and the user is able to create their own user types
and statues that derive from these.
Although that sounds like a laudable goal on the surface, the effect is to delegate database design to your users. Database design, because the effect of your desire to set foreign key references to a subset of the rows in entity_type_entity_status_link means each of those subsets is a defacto, unnamed table.
This approach never ends well.
What you've developed is the "One True Lookup Table". Google that for a host of reasons why OTLT is an anti-pattern.
The best solution is to model real things in your tables. (Entity isn't a real thing. It's an abstraction of a real thing.) Something along the lines of either
create table file_status (
file_status varchar(30) primary key
);
or
create table file_status (
file_status_id integer primary key,
file_status varchar(30) not null unique
);
would work well for file statuses.
In the case of the second one, you can set a foreign key reference to either the id number (saves space, requires an additional join) or to the status text (takes more space, eliminates a join). Note that you need the unique constraint on the status text; your original design allows the user to enter the same text multiple times. (You could end up with 30 rows where entity_type.name is 'File'.
You should use triggers for that.
MySQL does not support constraints of the form that will prevent what you want.