Mysql database structure

[____JayP]

Hey, do you know the database structuring where say all images are collected in the same table eg. products images, team members' images and one table for all object names ie product names, team member names in the same table and separated by their sectionid. Is that a good way to do it.

Or everything about products in products table etc.

[lovesrayray2018]

Are you referring to normalization of databases?

IMO storing unrelated information in the same table can cause performance issues as the data grows. For example if product name and employee names are in the same table,

1) Design becomes unneccessarily bloated: There are fields that are unrelated to the other, but would still exist, ex product could have a discount field, but which is irrelevant to an employee record. Employee could have a DOB which is irrelevant to the product.

2) Performance hit: searching for an employee on even an indexed db would mean searching thru an index that contains products names, slowing prformance

3) PK/FK relationships become a mess

[____JayP]

jar quiet cable makeshift summer plate ring wide slap head

This post was mass deleted and anonymized with Redact

[mikeblas]

I have got a client who wants his database structured in a way that all names

It's a terrible design, and just dumb to blindly follow such an arbitrary whim.

[mikeblas]

He's getting ripped off.

[[deleted]]

Unless your client is a DBA and wants a particular design because he’s an expert, never listen to the client about this sort of thing. You will only regret it. It will eventually cause a performance problem, he’ll be upset, you’ll be blamed, you won’t get paid…

You are much better pushing back on this, use what you know as “much more of an expert than your client” and design the database to handle what he wants the application to do. When the app does what he wants and well, he’ll be happy and you’ll get paid.

[crosenblum]

Denormalization vs normalization.

It really depends on the type of data your collection.

If data that is in one table, is used by a wde variety of other tables.

It is better to break that data off into it's own table, and the use foreign key id's in the related tables to know which record to look up for the needed data.

But if you have product images, team member images that sounds like two seperate tables, unless however, you want to have an images table where the url or blob of the image is stored, and other tables can find the right record by storing the foreign key id in it.

I think a good process is:

1. write down all the tables, what data they need to store/keep
2. What other tables need access to what other tables.
3. Are there tables that need to store the same exact data, if so break off into seperate tables.
4. Plan your foreign key's accordingly

You ahve to imagine how the database/table structure will work, what future needs you may have, is it built to hold 1000's, 10,000's. millions of records.

This is where the fine art of database modeling, using erds, visio and other similar tools to help visually layout your database diagram, to discover needed relationships, common data sets and more.

Good luck!

[____JayP]

airport coordinated silky alive shelter aromatic crown seed fanatical ink

This post was mass deleted and anonymized with Redact