Soldato
I'd politely agree Ergates.
Database table help
- Thread starter hargi
- Start date
Personally, i'd be implementing the DB same as @billysielu stated; Images, Sections, SectionImages.
That way would then allow you to later add videos with an extra 2 tables (provided that videos follows the same rules for images); Videos, SectionVideos.
Normalisation, along with keeping related data together, reducing NULLs and duplicates. Also, allows for scalability and refactoring with minimal redesign. DB design was one of my favourite parts of programming. Also, telling a new client, that their current DB would not accommodate the new application they wanted. So I told the account managers that the DB would have to be redesigned from scratch, as I would not touch it with a hack and botch job to save the client money, and get us the contract.
That way would then allow you to later add videos with an extra 2 tables (provided that videos follows the same rules for images); Videos, SectionVideos.
Normalisation, along with keeping related data together, reducing NULLs and duplicates. Also, allows for scalability and refactoring with minimal redesign. DB design was one of my favourite parts of programming. Also, telling a new client, that their current DB would not accommodate the new application they wanted. So I told the account managers that the DB would have to be redesigned from scratch, as I would not touch it with a hack and botch job to save the client money, and get us the contract.
Soldato
Yes hacking and bodging due to scalability can be forgiven, but rubbish design that has been neglected over many years is not excusable. I agree, redesign will save time and money in the long term.