database-relations

How would you design your database to achieve this functionality? Consider a scenario where we want to create a product relation (package) ... Say that we create a ProductTbl prod_id prod_name prod_fee 1 prepaid-A 19 usd 2 prepaid-B 29 usd 3 prepaid-C 39 usd 4 internet 9 usd 5 mms 1 usd 6 email 3 usd We want to offer a product package that provides better fees for customer. E.g. if customer choose prepaid-A + internet + mms they will have a pkg fee by 25 usd (instead of 29 usd). DESIGN A pkg with same combination should only exist once. A pkg can have unlimited number of products, if possible.

The scenario is: How can an Account give ratings to another account? This results in two lists on the Account. Those who I have rated and those who have rated me. (my_ratings and ratings_given) This boils down to: How can multiple 1 - N relationsips to the same entity work in Mongoid? In Mongoid's Docs it says you can use has_many and belongs_to to link the entities together. I currently have this on Account has_many :ratings, :as => "my_ratings" has_many :ratings, :as => "ratings_given" and this on Ratings : belongs_to :user, :as => 'Rater' belongs_to :user, :as => 'Ratie' The docs don't

This is what I'm trying to do: I have 2 tables... CREATE TABLE `parent` ( `id` int(11) NOT NULL AUTO_INCREMENT, `data` text, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8; CREATE TABLE `child` ( `parent_id` int(11) DEFAULT NULL, `related_ids` int(11) DEFAULT NULL, KEY `parent_id` (`parent_id`), KEY `related_ids` (`related_ids`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; And then a constraint: ALTER TABLE `parent` ADD FOREIGN KEY (`id`) REFERENCES `child` (`parent_id`); As you can see the table parent has an auto-incremented primary key "id", which is also being used as a

A DB design question: when do you decide to use 1 to 1 relation tables? One of the places I see this is, for example, when you have a User and UserProfile table, people split them instead of putting all columns just in a User table. Technically, you can just put all the columns in one table since their relationship is 1-to-1. I know someone said that for the UserProfile table, over time you need to alter table to add more columns, but I really don't think this is a strong reason to split the tables. So, if I'm to design a User table and UserProfile table, is it better for me to just do it in

I have entities: @Entity public class A { @PrimaryKey(autoGenerate = true) public long id; public A() {} } @Entity() public class B { @PrimaryKey @NonNull public String id; public String oneCId; public String anotherCId; public long aId; public B() {} } @Entity public class C { @PrimaryKey @NonNull public String id; public String value; public C() {} } and some POJOs: public class AWithB { @Embedded public A a; @Relation(parentColumn = "id", entityColumn = "aId") public List<BWithC> bWithC; public AWithB() {} } public class BWithC { @Embedded public B b; public C oneC; public C anotherC;

For a Symfony2 project I had to create a relationship between a blog post and so called platforms. A platform defines a specific filter based on the domain you use to view the site. For example: If you join the site by url first-example.com, the site will only provide blog posts, which are connected to this specific platform. To do so, I created two entities Post and Platform. Afterwards I mapped them together with a Many-To-Many relationship. I'm trying to retrieve data via this Many-To-Many relationship from the builtin function findBy() in Doctrines' EntityRepository . // every one of these

Can I have a column in my values table (value) referenced as a foreign key to knownValues table, and let it be NULL whenever needed, like in the example: Table: values product type value freevalue 0 1 NULL 100 1 2 NULL 25 3 3 1 NULL Table: types id name prefix 0 length cm 1 weight kg 2 fruit NULL Table: knownValues id Type name 0 2 banana Note: The types in the table values & knownValues are of course referenced into the types table. NULLs in foreign keys are perfectly acceptable. Dealing with NULLs in foreign keys is tricky but that does not mean that you change such columns to NOT NULL and