relational-database

I want to start using table relations in a new project. After some googling I got 2 tables set up as InnoDB: The keys I want to link are ->users->userid (primary) ->sessions->userid (index) The only thing that I don't understand in this process is what the different settings for "On update" and "On delete" do The options here are: -- (nothing?) Cascade (???) Set Null (sets everything to null?) No action (well duh...) Restrict (???) I basically want the data in sessions to be deleted when a user is completely deleted This since the sessions will only be deleted when the expiration is detected

A cross join performs a cartesian product on the tuples of the two sets. SELECT * FROM Table1 CROSS JOIN Table2 Which circumstances render such an SQL operation particularly useful? If you have a "grid" that you want to populate completely, like size and color information for a particular article of clothing: select size, color from sizes CROSS JOIN colors Maybe you want a table that contains a row for every minute in the day, and you want to use it to verify that a procedure has executed each minute, so you might cross three tables: select hour, minute from hours CROSS JOIN minutes Or you

I have multiple table chaining like so: Table1 product_id SERIAL NOT NULL, name varchar, Table2 ( kept separate from table1 because same product name but can be different color ) table2_id product_id integer, color varchar, FOREIGN KEY (product_id) REFERENCES table1 (product_id) ON DELETE CASCADE table3 ( kept separate from table2 because same product color but can be different size) table3_id table2_id integer, size varchar, FOREIGN KEY (table2_id) REFERENCES table2 (table2_id) ON DELETE CASCADE e.g product data could exist in such a manner: a chair (name) - red (color) - 100cm(size) a chair

I'm trying to create an inventory management schema where I can track the stock of various options related to products. A product may have any number of options, but for this example I'll use "size" and "color" options. I've come up with three tables: CREATE TABLE shop_options ( option_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, option_name VARCHAR(40) NOT NULL, PRIMARY KEY (option_id) ); INSERT INTO shop_options (option_id, option_name) VALUES (1, 'Size'); INSERT INTO shop_options (option_id, option_name) VALUES (2, 'Color'); CREATE TABLE shop_option_properties ( prop_id INTEGER UNSIGNED NOT

I'm trying to set up a relationship in Core Data. I have a list of Trees, and each Tree will have a list of Fruits. So I have a Tree entity and a Fruit entity. In code, I will want to list the Trees, in a table view for example. When you click on a Tree, it should then display a list of fruits that growing on that Tree. How do I set up this relationship? Do I need to give the Fruit an attribute called tree? And how do I set the relationship in code, for example when I create a Fruit how do I associate it with a given Tree ? Soleil, This is quite simple. First of of all, your model should look

I'm making a website and I need to store a random number of data in my database. for example: User john may have one phone number where jack can have 3. I need to be able so store an infinite number of values per user. I couldn't find how to do this anywhere, Hope you can help me! :) I am a novice in Relational databases. You create a separate table for phone numbers (i.e. a 1:M relationship). create table `users` ( `id` int unsigned not null auto_increment, `name` varchar(100) not null, primary key(`id`) ); create table `phone_numbers` ( `id` int unsigned not null auto_increment, `user_id`

I've been designing a database for an online store system. The question that I've come across by reading some posts in this website is that although I can use composite primary keys in the case I'm gonna explain below, is it really a bad practice (according to the posts I read in this respect over stackoveflow, many says it is a bad practice so that's why I'm asking). I want to store payments for the orders in a separate table. The reason is that, an order can have many items which are handled in a separate table in the form of many to many relationship. Now, if I don't use composite primary

Can someone explain to me the advantages and disadvantages for a relation database such as MySQL compared to a graph database such as Neo4j? In SQL you have multiple tables with various ids linking them. Then you have to join to connect the tables. From the perspective of a newbie why would you design the database to require a join rather than having the connections explicit as edges from the start as with a graph database. Conceptually it would make no sense to a newbie. Presumably there is a very technical but non-conceptual reason for this? There actually is conceptual reasoning behind both

Which of the following options, if any, is considered best practice when designing a table used to store user settings? (OPTION 1) USER_SETTINGS -Id -Code (example "Email_LimitMax") -Value (example "5") -UserId (OPTION 2) create a new table for each setting where, for example, notification settings would require you to create: "USER_ALERT_SETTINGS" -Id -UserId -EmailAdded (i.e true) -EmailRemoved -PasswordChanged ... ... "USER_EMAIL_SETTINGS" -Id -UserId -EmailLimitMax .... (OPTION 3) "USER" -Name ... -ConfigXML Other answers have ably outlined the pros and cons of your various options. I