This question already has answers here:
How to implement one-to-one, one-to-many and many-to-many relationships while designing tables?
(4 answers)
Closed 2 months ago.
Imagine I want to create a SQLite database of films, where the columns correspond to: title publication year, genre... How would you do it to store a list of actors in the database? Consider that:
Since the number of actors may vary from film to film, I cannot use one column per actor.
SQLite does not have a data type that corresponds to a list.
I want to use, for example "SELECT filmname FROM table WHERE X". Where X would be something that indicates if an actor is present in the film. I would like to be able to use a single or multiple actors on X
The best thing I though is to use a single string, like "actor1_actor2", and then apply "WHERE actorname LIKE %actor1". But that would allow me to filter films by only one actor.
Thanks!
You create tables movies, actors and a separate bridge table movies_actors for defining your many-to-many relationship (movie<->actor). The simplest form of the bridge table includes two columns, such as movie_id and actor_id, and two foreign keys: movies_actors.movie_id -> movies.id and movies_actors.actor_id -> actors.id.
I would suggest, create a mapping separate table for the actress with a mapping key as Film's primary table. so that you can run all type of query operations on your table structure.
Related
I'm using Sails.js to build an API for an existing database. Unfortunately, modifying the structure of the database is not an option.
Many tables in the database have status columns of one type or another. They tend to have single-letter values that don't make sense without context. Context is provided by a "lookup" table in the database with 3 primary keys: table_name, column_name, and column_contents. Therefore, if I have a letter returned as a status, I can do a query against the lookup table and check a fourth column, description.
I'd love to configure my Sails.js models to understand all this, but it seems that one-to-many relationships can only be set up for tables with a single primary key. Is that correct?
Based on the "many-to-many" workaround, I assume the sails way to solve this would be to create new tables that are subsets of the "lookup" table (each for a single instance of table_name, column_name). Is there a better way?
I want to make unique constraint in cassandra .
As i want to all the value in my column be unique in my column family
ex:
name-rahul
phone-123
address-abc
now i want that i this row no values equal to rahul ,123 and abc get inserted again on seraching on datastax i found that i can achieve it by doing query on partition key as IF NOT EXIST ,but not getting the solution for getting all the 3 values uniques
means if
name- jacob
phone-123
address-qwe
this should also be not inserted into my database as my phone column has the same value as i have shown with name-rahul.
The short answer is that constraints of any type are not supported in Cassandra. They are simply too expensive as they must involve multiple nodes, thus defeating the purpose of having eventual consistency in first place. If you needed to make a single column unique, then there could be a solution, but not for more unique columns. For the same reason - there is no isolation, no consistency (C and I from the ACID). If you really need to use Cassandra with this type of enforcement, then you will need to create some kind of synchronization application layer which will intercept all requests to the database and make sure that the values are unique, and all constraints are enforced. But this won't have anything to do with Cassandra.
I know this is an old question and the existing answer is correct (you can't do constraints in C*), but you can solve the problem using batched creates. Create one or more additional tables, each with the constrained column as the primary key and then batch the creates, which is an atomic operation. If any of those column values already exist the entire batch will fail. For example if the table is named Foo, also create Foo_by_Name (primary key Name), Foo_by_Phone (primary key Phone), and Foo_by_Address (primary key Address) tables. Then when you want to add a row, create a batch with all 4 tables. You can either duplicate all of the columns in each table (handy if you want to fetch by Name, Phone, or Address), or you can have a single column of just the Name, Phone, or Address.
I'm new to DynamoDB - I already have an application where the data gets inserted, but I'm getting stuck on extracting the data.
Requirement:
There must be a unique table per customer
Insert documents into the table (each doc has a unique ID and a timestamp)
Get X number of documents based on timestamp (ordered ascending)
Delete individual documents based on unique ID
So far I have created a table with composite key (S:id, N:timestamp). However when I come to query it, I realise that since my id is unique, because I can't do a wildcard search on ID I won't be able to extract a range of items...
So, how should I design my table to satisfy this scenario?
Edit: Here's what I'm thinking:
Primary index will be composite: (s:customer_id, n:timestamp) where customer ID will be the same within a table. This will enable me to extact data based on time range.
Secondary index will be hash (s: unique_doc_id) whereby I will be able to delete items using this index.
Does this sound like the correct solution? Thank you in advance.
You can satisfy the requirements like this:
Your primary key will be h:customer_id and r:unique_id. This makes sure all the elements in the table have different keys.
You will also have an attribute for timestamp and will have a Local Secondary Index on it.
You will use the LSI to do requirement 3 and batchWrite API call to do batch delete for requirement 4.
This solution doesn't require (1) - all the customers can stay in the same table (Heads up - There is a limit-before-contact-us of 256 tables per account)
I am using SQL Server2005 with asp.net. I want validation at server side to restrict duplicate entries, Here i am using two tables companies and Branches. In Branches Table i had maintain a foreign key of CompanyId. In Branches the BranchName can be duplicate but not for the Particular CompanyId.
Companies Table:
Columns: CompanyId (Primary Key), CompanyName
Branches Table :
Columns: BranchId(Primary Key), BranchName, CompanyId (Foreign Key).
Company Id can be Repeat multiple times, one to many Relationship.
Which query I use to that allow duplicate but not for the same CompanyId?
You want a constraint that enforces uniqueness against both the CompanyID and BranchName columns. This can either by the primary key for the table (as Tim has recommended), or a UNIQUE constraint:
ALTER TABLE Branches ADD
CONSTRAINT UQ_BranchNamesWithinCompanies UNIQUE (BranchName,CompanyID);
You can decide which order to put the columns within the constraint, based on how frequently searches are performed in the table based on the two columns. I.e. you're actually creating an index on these columns, so you may as well use it to improve some query performance.
The above ordering was based on a guess that you might search for branch names without reference to a particular company. If you're always searching within a company, and are performing prefix searches (e.g. CompanyID=21 and BranchName like 'Lon%'), then you'd want to reverse the order of the columns.
You could create a composite primary key from BranchName+CompanyId.
http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx
how can I store and retrieve in SQLite database multiple values for the same row of the same column?
i.e. I have a product column and another column is stores, where I put in all the stores, where it is possible to get this product:
Product: iLamp;
Stores: River's; McWay; Lonnie's; ...
How can I implement this?
Thank you in advance.
If you're smart, you won't do this. Because when it comes time to figure out which stores stock the item, your queries will be hideously deformed. So will those of your stock control application when they try to insert and delete stores. What you'll end up with is what I like to call SQL gymnastics, spending more and more time trying to do SQL in the most bizarre way, simply due to a bad design choice.
Seriously, store these in different rows in the database, as Codd intended.
It's far easier (and faster in terms of the DBMS grunt) to combine multiple rows into a single semicolon-separated string than to break that string into elements.
A schema such as this would suffice:
Products:
ProdCode integer primary key
ProdDesc varchar(50)
Stores:
StoreCode integer primary key
StoreDesc varchar(50)
StockLevels:
StoreCode integer \
ProdCode integer / primary key
Count integer
like others have mentioned, you could store it as a comma separated string, and then put that in your database, but like ocdecio mentioned, the way you have your tables right now is bad a design. You should consider doing something like adding another table, like a PRODUCT_TO_STORE table that has two columns, one has the key of a product, and the other column has the key to a store. Then there is a relationship between products and stores, and helps normalize your data, which in most cases, is a good thing. Then when you need to find all the stores a product is in you could just perform a query on that PRODUCT_TO_STORE table.
I would use something simple like JSON. However this is bad db design since it is not normalized.
change the schema.
do not store multiple values in the same row's column.
add a new table where the multiple values can be stored in their own rows
bad table deisgn:
parents:
ParentID, values, other columns
good table design:
parent
parentID, other columns
child
parentID, childID, value
Either store as a comma-separated list for each store or add multiple rows one for each pair "Store"-Product".