Search results

Whenever you encounter two tables with the same structure and meaning that is usually considered a reg flag - not necessarily completely unjustified in every case but at least worth a careful second look to see if your design really makes sense. The reason it's considered a questionable design...

There are a few things to look out for. For example, features that depend on row order may not work the same way; uniqueness constraints and foreign key constraints behave differently with null values; cascading referential integrity is different. If you are using bound forms then consider...

No I'm not at all. I'm assuming based on what the OP said that he wants to learn those concepts. Sure, but the material the OP had been reading set a bad example. It was just wrong and as a result he had learnt things wrong. I fail to see why it would be a problem to suggest he learn from an...

Which is exactly why I'm suggesting he learn the basics from a more reliable source before going further. This forum is not the place for a tutorial. Any attempt here to solve a specific design problem without the opportunity to analyse the details of the situation is always going involve some...

You should be more careful about your choice of learning materials and much more sceptical about material you find on some random website. Normalization isn't about whether some item of data changes or repeats for different rows. It's about what business rules (called functional, multi-valued...

Welcome to the forums, Having a separate column for each month generally would not be a good database design because, among other things, it means any data access, query and reporting logic would have to be repeated for each column. Also, it's not typically a good idea to modify database table...

This isn't exactly a table design problem, it's more a question of user interface design. Your form ought to retain the values until the record is successfully saved. As far as table design goes, it isn't necessary to concatenate the values into one PropertyID value just to implement the...

There are no "rules" of database design. Design theory and practice is science and engineering, not religion. Good data management practitioners learn the foundations of their profession; they learn about the tools and techniques available to them and then apply that knowledge to analyse and...

If you are just starting out to build a technology-based career then I would recommend you try to do the opposite though. Definitely try to work in a development team rather than as a one man operation. You'll learn more that way from fellow team members. The most rewarding parts of my career...

There is no such thing as free software, but yes, you have to pay extra for features and support over and above the "community" GPL version of MySQL. On Windows, Microsoft SQL Server is in my view a much better value deal than MySQL. You get more in the box and you benefit from better...

Your teacher may have more than one thing in mind. He may just mean Jet/ACE - the file-sharing data engine that is bundled with Access. Jet/ACE is designed for desktop/file-server database applications and it is not a client-server DBMS. It doesn't support anything like the kind of scalable...

Just a general comment but I believe the most important lesson to learn about migration is this: the time to migrate a database to Azure or any other target platform is at the beginning of your development project, never near the end. It makes no sense to develop on one platform if you actually...

Try this: SELECT PaymentId, PaymentPayer, PaymentDate, PaymentAmount FROM YourTable AS t WHERE PaymentDate = (SELECT MAX(PaymentDate) FROM YourTable WHERE PaymentPayer = t.PaymentPayer); Just to underline what Brian said: FIRST and LAST are practically useless. Typically when you see...

For an INNER join (like the example you give here) there is no difference. A condition in the ON clause gets treated the same as if you put it in the WHERE clause. Compare the execution plans to be sure. In the case of an OUTER join there may be a big difference. Logically speaking an OUTER...

I wouldn't even call that much of a "rule". It's very common and perfectly reasonable to store calculated values. One reason for doing that is as an optimisation to avoid repeated calculations. Another reason might be to permit archiving of certain data while preserving the summary results...

Possibly the question is about the content of identifiers intended to be used by customers (e.g. customer numbers or order numbers). In some cases you might want to randomize such identifiers (rather than allocate them in a simple numeric sequence for example) to make them harder to guess. If...

If by "access database" you mean a Jet/ACE database then it can't be done. A Jet/ACE database is completely exposed to anyone who can open it. Hiding data behind code won't help unless your intention is to deceive your users into thinking their data is subject to a level of security that in fact...

What identifies a Character/Person in the business domain? That is the requirement you should aim to fulfill in your database design. Names of people don't typically make good identifiers because different people often share the same names. That said, there certainly are scenarios in which names...

There seems to be nothing obviously "wrong" with your design. Normalization really has nothing to do with eliminating data that is "repeating" - although it is sometimes wrongly described that way. Do you need to record a history of changing prices? If so then you might want to add some dates...

Why? If you plan to treat these nulls as zeros then you might reconsider whether it is worth permitting them into the table in the first place. Nulls inevitably complicate query logic and will have other undesirable effects on the results you get out of the database.