Search results

  1. B

    Am I normalizing too far?

    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...
  2. B

    Am I normalizing too far?

    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...
  3. B

    Am I normalizing too far?

    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...
  4. B

    Auto generating fields

    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...
  5. B

    Primary Key Problem

    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...
  6. B

    Designing a database with many (100-300) fields.

    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...
  7. B

    What's wrong with Access?

    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...
  8. B

    What's wrong with Access?

    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...
  9. B

    What's wrong with Access?

    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...
  10. B

    SSMA and Migration Path Planning

    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...
  11. B

    How do I use "LAST" in query?

    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...
  12. B

    Criteria in Join

    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...
  13. B

    Is it every ok to store a calculated value in a table?

    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...
  14. B

    primary keys

    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...
  15. B

    Security Access Db..

    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...
  16. B

    What should I use as my Primary Key

    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...
  17. B

    Table design for engineering valve pricing

    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...
  18. B

    Null Values

    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.
  19. B

    Is access unstable

    namliam, You are so wrong in so many ways. IT Department are presumably the ones charged by the executive officers of the company with responsibility for information security, integrity and availability. They therefore ARE responsible for supporting information systems and being accountable...
  20. B

    Database relationships

    Nothing wrong with that. What matters is that you apply some sound principles in your design process: identifying the business rules, keys, datatypes, Normal Form, and so on.
Back
Top Bottom