data-modeling

We develop a commercial application. Our customers are asking for custom fields support. For instance, they want to add a field to the Customer form. What are the known design patterns to store the field values and the meta-data about the fields? I see these options for now: Option 1 : Add Field1, Field2, Field3, Field4 columns of type varchar to my Customer table. Option 2 : Add a single column of type XML in the customer table and store the custom fields' values in xml. Option 3 : Add a CustomerCustomFieldValue table with a column of type varchar and store values in that column. That table

Every Customer has a physical address and an optional mailing address. What is your preferred way to model this? Option 1. Customer has foreign key to Address Customer (id, phys_address_id, mail_address_id) Address (id, street, city, etc.) Option 2. Customer has one-to-many relationship to Address , which contains a field to describe the address type Customer (id) Address (id, customer_id, address_type, street, city, etc.) Option 3. Address information is de-normalized and stored in Customer Customer (id, phys_street, phys_city, etc. mail_street, mail_city, etc.) One of my overriding goals is

Using this modified example from the Rails guides , how does one model a relational "has_many :through" association using mongoid? The challenge is that mongoid does not support has_many :through as ActiveRecord does. # doctor checking out patient class Physician < ActiveRecord::Base has_many :appointments has_many :patients, :through => :appointments has_many :meeting_notes, :through => :appointments end # notes taken during the appointment class MeetingNote < ActiveRecord::Base has_many :appointments has_many :patients, :through => :appointments has_many :physicians, :through =>

The "party model" is a "pattern" for relational database design. At least part of it involves finding commonality between many entities, such as Customer, Employee, Partner, etc., and factoring that into some more "abstract" database tables. I'd like to find out your thoughts on the following: What are the core principles and motivating forces behind the party model? What does it prescribe you do to your data model? (My bit above is pretty high level and quite possibly incorrect in some ways. I've been on a project that used it, but I was working with a separate team focused on other issues).

Our database is designed based on EAV (Entity-Attribute-Value) model. Those who have worked with EAV models know all the crap that comes with for the purpose of flexibility. I asked my client about the reasons why using EAV model (flexibility), and their response was: Their entities change over time. So, today they may have a table with a few attributes, but in a month time, a few new attributes may be added, or an existing attribute may be renamed. They need to produce reports to get back to any stage in time and query the data based on the shape of entities at that stage. I understand this

I am just trying to figure out how Facebook's database is structured for tracking notifications. I won't go much into complexity like Facebook is. If we imagine a simple table structure for notificaitons: notifications (id, userid, update, time); We can get the notifications of friends using: SELECT `userid`, `update`, `time` FROM `notifications` WHERE `userid` IN (... query for getting friends...) However, what should be the table structure to check out which notifications have been read and which haven't? Atif Mohammed Ameenuddin I dont know if this is the best way to do this, but since I