After you have done a good normalization, do you still need to index the table? How is this going to affect the performance? Will it even affect the performance in some way after a good normalization?
Which columns are usually indexed if you already have the primary key and the foreign key?
It’s seems like it’s already effective to normalize a database. But, I might have skipped how indexing affects the database. Is this only effective when queries are used? How does this work/perform and make a database better?
2
Yes. In fact, you very well may need to pay more attention to your indexes. Normalization is about optimal storage. That’s often at odds with retrieval speed, as more complex queries with complicated joins are used. Sometimes people maintaining databases that require fast retrieval speeds will de-normalize, or arrange their data in slightly less normalized structures to make retrieval easier.
3
I think you misunderstood what indexing does for database performance.
An index helps the database find rows. Indexes are specialized data-structures that, in exchange for extra disk-space and some performance when inserting and updating, help the database engine home in on matching rows.
Because they take extra space and cost (a modicum of) performance to keep them up-to-date, you as a database designer must create indexes explicitly to suit your application and query patterns.
Indexes are orthogonal to database normalization.
Yes after normalization you still need indexing.
The tables you are working with benefit just as much as the tables you had before normalization. In actuality, on their own they’re just the same: tables.
One thing you have to consider though, indexes help you find your way through your data faster. Normalizing a design of a database is always good, but sometimes for performance reason you have to denormalize the implementation. But that’s only on a case by case basis.
Yes.
Indices are a method to speed up searching for the data. Some queries are by primary keys, which are usually implicitly indexed by the database engine, but other queries are likely to use other columns. Often some queries search by columns that are not even unique and thus can’t become primary keys after any normalization. You will probably have to index such columns.
There is only one way to know which indices to create. Take all queries in the application, find representative example parameters for them and have the database engine show their query plans (all database engines have EXPLAIN, EXPLAIN QUERY PLAN or similar command; it is called differently in different engines) and test how long they take. Than create indices that speed up the ones that were slow. And don’t forget to drop again indices that you tried but didn’t help to avoid wasting resources.
Indexes are generally needed in all but the smallest tables. Pretty much every foreign key should be indexed and just setting up an FK does not mean you have an index (at least not in some databases, check you db documentation). Fields you frequently join on or use in where clauses should be indexed if they are ones that would benefit (you need a certain amount of variablity in data so Booleans don’t benefit for instance) and ones where it is possible to index.
However, every index slows down insertsupdatesdeletes while speeding up selects, so choose your indexes carefully.
Indexes are critical to acceptable performance in a database.
For a third normal form you will definitely need indexes on all the primary keys.
Whether you need any other indexes depends on how your database is used.
For example if you regularly search for customers in a particular ZIP code, then, it might be a good idea to index the zip_code column in the customer table.