Tag Info

Hot answers tagged

4

For very small tables, fragmentation is not only irrelevant, but nearly impossible to control. The first eight pages are allocated out of mixed extents, which are almost always going to be non-sequential. Only after an index has more than eight pages will it be allocated additional pages from uniform extents. At fewer than 1,000 rows, your clustered index ...


4

Much of this is a matter of taste and style. And more importantly: specific requirements and consistent conventions. However, there are good reasons for this generic advice: CREATE TABLE item ( item_id serial PRIMARY KEY, grp_id integer NOT NULL REFERENCES grp(grp_id) ); If you have an item_id, better make it unique and ideally a surrogate ...


3

You need a compound unique index. Suppose your table is called photos. You can do this: CREATE TABLE photos_new LIKE photos; ALTER TABLE photos_new ADD UNIQUE INDEX pid_tid_index (pid,tid); INSERT IGNORE INTO photos_new SELECT * FROM photos; ALTER TABLE photos RENAME photos_old; ALTER TABLE photos_new RENAME photos; If it works out, then run DROP TABLE ...


3

Here are the layers of abstraction that you need to go through to track who has (pays for) a GSM phone: Note that this is good for a point in time. If you need to track changes over time then everything becomes many-to-many with start/end dates in the intersection entities.


2

I think the conflict you mention stems from confusing data logic and business logic. The business rule may be that for whatever reason, you do not want to have the same product for multiple users of the same client. However, there is really no need to put this constraint into the database. If you don't want to allow this, put that check into your ...


2

This is opinion based, or at least quite subjective in the real world with the best solution varying depending on a number of factors the relative importance of each different people with disagree on, unfortunately. The question is whether you should ever create a surrogate key when there is an apparently perfectly suitable candidate key (compound or not) ...


2

The core of the database must be the account, also the customers. They are giving the money for the company, there isn't any other possibility. Logically everything should reference some of an account. Second, the users authentifies themselves for the network of the company by their sim ids. Every sim card should have exactly one account (which will pay for ...


2

If you have common attributes across non-exclusive tables, you should consider normalizing your tables. It appears that Client, Employee, Manager, and Developer are all sub-types of the Person entity. As such any attributes common to all types should be in the person entity, and attributes for the other entities should depend only on that sub-type. I ...


1

I'd suggest you have a think about this system's use cases. Work out in your own mind how the queries will look for the given design and for your alternative. Include scenarios where people move between slots. What do updates look like? Can business constraints be enforced in DRI? Can the desired values still be found? Having actual examples to talk ...



Only top voted, non community-wiki answers of a minimum length are eligible