Search results

Does a primary key truly need to be unchangeable? Answer: no it doesn't. It's true that changing key values may need special consideration in database design and may present some practical problems but in principle and in many cases in practice there is nothing fundamentally wrong with having...

ions, Jet is a file-sharing system, not a client-server DBMS. Certain optimisations are possible but all the processing happens on the client machine and therefore all of the data necessary to complete that processing has to come over the wire. As others have said, in your case the data and...

Normalization is never concerned with dependencies between different relations so there's no reason why having derived data in another table would violate any normal form. That still doesn't mean it's a good design of course! This doesn't seem to have much to do with double entry accounting...

How would you produce a Balance Sheet and a P&L without a double entry ledger? You would still need some way of mapping each transaction item to Balance Sheet codes and P&L codes. It seems like the "obvious" way to do that in a database is with two or more row(s) in a table (or possibly tables)...

You could do that but you probably shouldn't. Consider Agile methods instead of estimating and fixing scope. Three months is too long to specify one system and a year is too long to deliver. Prototyping also tends to be frowned upon these days. In my view it can make sense for certain systems...

Adigga1, Your requirements sound pretty standard for a small / medium enterprise (300 users). You should be considering a client-server DBMS such as Oracle / SQL Server but I suggest you take advice from whoever is responsible for delivering the solution about the actual technology choices...

I didn't intend to make any point about surrogate or natural keys. Gemma has it right. I was simply pointing out that it is candidate keys that are significant rather than primary keys. I think that point doesn't get made often enough. As regards referential integrity. I tested it with Access...

Just to expand a bit on what Doc Man said, in case further definitions help. A Superkey is a set of attributes that are collectively unique. Taken together the set of values for those attributes will be different on every row. A Candidate key is a superkey which is also minimal. In other...

There is actually a formal rule for evaluating such situations. Date and McGoveran's Orthogonal Design principle, "POOD" (see "Date on Database", Apress). Roughly speaking POOD means it should never be possible for the same tuple (any proper superkey in fact) to be present in more than one...

Please explain why you would do that. I suggest you do whatever you are doing on your server if possible. It might be hard to justify purchasing an edition of SQL Server just to run on a laptop.

You have misunderstood me. I am in favour of the relational model and I think it has a great future. I am not a fan of SQL however and I hope SQL will be replaced by better things. SQL is not relational. I think the biggest threat to the relational model and relational databases is actually...

All SQL systems use a multi-set model (duplicate rows) rather than E.F.Codd's set-based model. Also they don't always support keys (for instance no key inheritence or keys on views). For these reasons among others they certainly don't conform to Codd's Information Rule or his Guaranteed Access...

An industrial strength Relational DBMS would be nice. :) (Access is not relational and nor are Oracle, SQL Server and other SQL-based database systems because the SQL model is quite different to the relational model. So I'd like a true RDBMS rather than a SQL DBMS)

Is the "query" you refer to actually a SQL view? Views are always unordered. ORDER BY is only valid in a view as part of a TOP query in which case the purpose of ORDER BY is purely to specify the selection criteria used by TOP, not to sort the results. If you want sorted results then use a...

Surely 3NF is a special (degenerate) case of BCNF. That 3NF exists at all seems to be a historical accident and mistake. 3NF looked strong enough to deal with FD-related anomalies until it was proven otherwise and BCNF became the newly improved result.

That's incorrect. A relation is in 3NF iff, for every non-trivial FD A->B, either A is a superkey OR B is a subset of some candidate key. A relation is in BCNF iff, for every non-trivial FD A->B, A is a superkey. Therefore BCNF is "stronger" than 3NF (and actually much more important in...