denormalization

Suppose I have a table of customers: CREATE TABLE customers ( customer_number INTEGER, customer_name VARCHAR(...), customer_address VARCHAR(...) ) This table does not have a primary key. However, customer_name and customer_address should be unique for any given customer_number . It is not uncommon for this table to contain many duplicate customers. To get around this duplication, the following query is used to isolate only the unique customers: SELECT DISTINCT customer_number, customer_name, customer_address FROM customers Fortunately, the table has traditionally contained accurate data. That

I'm using Rails and MySQL, and have an efficiency question based on row counting. I have a Project model that has_many :donations . I want to count the number of unique donors for a project. Is having a field in the projects table called num_donors , and incrementing it when a new donor is created a good idea? Or is something like @num_donors = Donor.count(:select => 'DISTINCT user_id') going to be similar or the same in terms of efficiency thanks to database optimization? Will this require me to create indexes for user_id and any other fields I want to count? Does the same answer hold for

Use case explanation We have a relational database with data about our day-to-day operations. The goal is to allow users to search the important data with a full-text search engine. The data is normalized and thus not in the best form to make full-text queries, so the idea was to denormalize a subset of the data and copy it in real-time to Elasticsearch, which allows us to create a fast and accurate search application. We already have a system in place that enables Event Sourcing of our database operations (inserts, updates, deletes). The events only contains the changed columns and primary

Let's say we have these tables: CREATE TABLE A ( id SERIAL NOT NULL PRIMARY KEY ); CREATE TABLE B ( id SERIAL NOT NULL PRIMARY KEY ); CREATE TABLE Parent ( id SERIAL NOT NULL PRIMARY KEY, aId INTEGER NOT NULL REFERENCES A (id), bId INTEGER NOT NULL REFERENCES B (id), UNIQUE(aId, bId) ); CREATE TABLE Child ( parentId INTEGER NOT NULL REFERENCES Parent (id), createdOn TIMESTAMP NOT NULL ); Is it possible to create a unique constraint on Child such that for all rows in Child at most one references a Parent having some value of aId ? Stated another way can I created a unique constraint so that the

I've started a new project and they have a very normalized database. everything that can be a lookup is stored as the foreign key to the lookup table. this is normalized and fine, but I end up doing 5 table joins for the simplest queries. from va in VehicleActions join vat in VehicleActionTypes on va.VehicleActionTypeId equals vat.VehicleActionTypeId join ai in ActivityInvolvements on va.VehicleActionId equals ai.VehicleActionId join a in Agencies on va.AgencyId equals a.AgencyId join vd in VehicleDescriptions on ai.VehicleDescriptionId equals vd.VehicleDescriptionId join s in States on vd

I have a web application that I am currently working on that uses a MySQL database for the back-end, and I need to know what is better for my situation before I continue any further. Simply put, in this application users will be able to construct their own forms with any number fields (they decide) and right now I have it all stored in a couple tables linked by foreign keys. A friend of mine suggests that to keep things "easy/fast" that I should convert each user's form to a flat table so that querying data from them stays fast (in case of large growth). Should I keep the database normalized

I've designed the database for the web-app i'm building "by the book". That is, I've: Created an E-R diagram containing the app's entities, attributes, and relationships Translated the E-R diagram in to a schema Translated the schema in to a "no-schema" form to model the database with (the database is a Cassandra (NoSQL) database). Everything is going well (so far). I've denormalized before with great results, and am curently implementing a part of the app which will use data that hasn't been denormalized yet. Doing so for this particular part will, I predict, increase performance somewhat

I read that in nosql (cassandra for instance) data is often stored denormalized. For instance see this SO answer or this website . An example is if you have a column family of employees and departments and you want to execute a query: select * from Emps where Birthdate = '25/04/1975' Then you have to make a column family birthday_Emps and store the ID of each employee as a column. So then you can query the birthday_Emps family for the key '25/04/1975' and instantly get all the ID's of the employees born on that date. You can even denormalize the employee details into birthday_Emps as well so