Search results

What most people call "one to one" very often means "one to zero or one". In other words one side of the relationship is optional. This is sometimes called Z-cardinality and is different from strict "one-to-one". Strict one-to-one relationships between two tables in most cases tend to be...

It's usually good practice to avoid or minimise the use of nulls. Nulls cause some queries to return results that are "incorrect" (i.e. the results won't correspond with the intended meaning of the database). Unfortunately SQL and SQL-style databases can make nulls difficult, though not...

No one can say for sure what is normalized or not because you haven't specified the dependencies you are supposed to be modelling. All we can do is make some guesses and assumptions based on attribute names. I expect this is homework so the important thing is that you know and can justify your...

Absolutely! :)

The biggest general problem is the one you are describing as "data entry control" - which fundamentally means inadequate implementation of business rules. More specifically: lack of data integrity constraints; weak typing; use of nulls. Such problems are a legacy of SQL and its implementations...

How about upsizing the database to SQL Server Express. 10GB is the limit there and if you need more you can consider upgrading to SQL Server Standard.

Dave, do you mean Build it first in Jet/ACE. Upgrade to SQL Server later ? I know people have suggested that before but I think it's bad advice for lots of reasons. Even at best it involves more work overall: creating two versions of the database instead of one. Very likely it may require a lot...

I think it's a poor analogy because serial numbers would be a natural key for dollar bills and they are as far as I know the only way to identify bills, which is exactly what autonumber columns ought not to be. Your example money queries are all about counting and aggregation, which misses the...

There is no such set of minimum permissions. A Jet/ACE database is and must be an open book as far as users are concerned because every user must be granted either read-only or read/write access to the database file itself. Is there a reason why you didn't or can't implement the database in SQL...

Creating your own "role-based security" by hiding data behind forms and other application-level code is a very, very dubious practice. It's really a form of "security theatre" - a way of deceiving legitimate users into thinking their data is subject to a level of security which in reality isn't...

Maybe you don't have to wait. You could start development on your own workstation (using SQL Developer Edition or Express). In some development teams the developers work on individual workstations and only deploy to the shared development server when they are ready to check in. That's a method...

True, and that alone is a good enough reason not to even consider using Jet/ACE for a system with 200 users. Larnu, what is your backup and recovery strategy? For the sake of argument, suppose you backed up such a database twice a day. In a crash you would be faced with losing up to 100...

20 points I guess would mean you need up to 760 rows. That's a very small table, not a long one. If updates need to be by human beings then you could make your user interface a grid like the one you originally posted. User interface design doesn't have to look the same as table design.

Enforcing the key in the database is more important. Put a uniqueness constraint (AKA key constraint / "unique index") on RA_PO_Nbr if there isn't one already. Don't rely only on procedural code in your forms to keep out duplicates - it won't.

I suggest you structure your table something like this: From To Fuel ---- ---- ---- A B 10 A C 15 B A 5 B C 5 C A 10 C B 5

De-duplicating and merging contacts has some complexities but there is lots of software and some common techniques to help you do it (Google for terms like fuzzy matching, householding and contact list de-duplication). Obviously you need to decide when and how it's appropriate to apply such...

Add a uniqueness constraint to your table. Data integrity belongs in the database, not just in forms. ALTER TABLE tbl ADD CONSTRAINT AK1_tbl UNIQUE (col1, col2, col3); Are you sure you really want to enforce uniqueness of names? Duplicate names are very common.

They are called "Recommendation Systems" or "Recommender Systems". A search of an academic index like CiteSeer or the ACM digital library will find thousands of references for you. Here's one: http://infolab.stanford.edu/~ullman/mmds/ch9.pdf

Think about what you want to achieve from your education. Are you just looking for some easy productivity gains or do you actually want to learn the basics of professional data management? If the latter then I think the advice to "learn by doing" - by starting to create a project in Access - is...

Here's a good place to start: Party Data Model.