Search results

A check box is a user interface element. There is no such thing in SQL Server because SQL Server is a DBMS and not an application development tool. SQL Server therefore has no feature for creating check boxes.

One table per distance? Why not just one table and have distance as an attribute in that table? If LocationID determines LocationName then I think you should not have both in that table. Are you familiar with what normalization means and what a non-key dependency is?

A design with a key plus one column per attribute (one column per "answer") is already in 5NF if it doesn't contain any non-key dependencies or nulls. It doesn't need any modification to be normalized. Putting all values in a single answer column has the obvious disadvantages I already...

You are asking an excellent question. I challenge people with the same question whenever I see tables or columns with names like "Question" and "Response", which always makes me think something is "wrong". A data model is a model for representing facts in a system. A questionnaire on the other...

There is nothing fundamentally wrong with using any candidate key for referential integrity. Both logically and practically speaking all keys are equal and "primary" keys are only as "special" as you want them to be.

My reply was directed at the OP's question. Nothing to do with wireless or Mike's reply.

I suggest you give some thought to the availability and integrity needs of the database. In a transaction processing system avoiding data loss is usually critical to the business, even for low volume data like yours. SQL DBMSs like SQL Server and MySQL have transaction logging so that your data...

.NET is the most widely used development platform on Windows. It's also the best supported by other applications and tools and it has many features to help you build high performance database applications. If you don't need the desktop database features of Jet/ACCDB then I think .NET is a better...

In SQL Server it is generally advantageous to use stored procedures for data access unless you have a good reason not to. As to the rest of your strategy, it sounds like you are struggling to make the most of an Access solution where you don't really need it. Is there some reason why you aren't...

Get some decent accounting software. Many of those packages are probably cheaper than Access. Writing code to produce invoices is surely a waste of your time.

Another possibility is that a Person may or may not have a tenancy: 1 -> 0..1 rather than 1->1. In that case you can keep the Tenancy table and make the Person foreign key column a candidate key of Tenancy as well (so that no more than one tenancy per person is permitted).

You can restore to Express from any edition provided the data file size doesn't exceed 4GB. Developer Edition has all the features of Enterprise Edition and runs on a desktop / laptop. It costs less than $50 and for development purposes only it is a much better option than Express.

Assuming that equipPrimary, equipSecondary and equipTertiary are not nullable and are functionally determined by the key(s) of the table then from a Normalization perspective there is nothing wrong with the design. It may or may not be a good idea to change the design for other unrelated reasons...

A Data Warehouse is a database that is subject-oriented (rather than designed to service an application), time-variant, integrated (presents a single consistent view of the enterprise) and non-volatile. Data Warehouses are a central component of most Business Intelligence solutions. OLAP is a...

It shouldn't do because they are two different tuples. Assuming A is key and B is not then A -> B certainly does not imply that B -> A. That is really an implementation detail. In principle a primary key need not be distinguishable from other candidate keys in the database at all. "Primary"...

I read this a few times and I don't understand it. Whatever you "believe" there is nothing in principle in the relational model that stops you changing a primary key or changing values in primary key attributes. All DBMSs I know of permit such changes. If you know of some system that doesn't...

As a rule I disregard anything on Wikipedia. Peter Chen (the inventor of ER modelling) defines a weak entity type as one whose identifying attributes include a relationship to another entity. The fact that a non-key attribute is a foreign key or exists in another table does not make a weak...

Interesting that you found the Oracle Financials schema unfriendly. It has been a few years since I last worked with it but I always found it to be one of the most well-designed and easiest to understand of any financial / ERP system I know. Heaps better than SAP or PeopleSoft anyway. Oracle...

If you haven't acquired it through education and study then what vocabulary you use may depend on what tools and techniques you have worked with. The concept of Weak/Strong entities and their corresponding Identifying/Non-identifying relationships exists in Object Role Modelling, in Chen, Barker...

Strong / Weak Entity is part of ER modelling terminology rather than relational design theory. Consider a relation with two candidate keys: A and B. A is also a foreign key. Now according to ER modelling convention if A is selected to be the "primary" key then it's a "weak" entity; if we call...