We currently have a settings hierarchy in our system that allows settings to be saved for an individual user, a setting group (each user can be tied to a single setting group, but the setting group is in a nested set so we query up the tree to check for inherited values from parent setting groups), or customer level settings (each user can be tied to one customer).
Currently we have three tables storing the setting values for each level:
user_setting_values
setting_group_setting_values
customer_setting_values
I have been asked by management (also the dude who originally wrote the system) to merge these tables into one single table that holds all the settings. He hasn't come up with a particularly good argument for doing it other than "it makes sense to have them all in one table".
So is this a good idea? What are the pro's and con's?
Pro: Less tables
Con: Always a good idea to avoid nulls, concolidating different levels normally leads to nulls values
If concolidated into one table there is typically two solutions for implementation
Using a type column if type of settings are the same per level, value reflects which level data relates to, e.g. user, group or customer.
Expand number of columns if setting types are different per level
Nulls used to indicate N/A values for a given column
If settings is of type yes/no storing value as booleans might be handy.
I'm developing a small application using the Clarizen API. The documentation references "pickup tables" numerous times, but the description
"Pick up tables are similar to the Regular entity types. Pick up tables usually contain limited set of fields and limited number of entities and are referenced from the other types of classes."
is meaningless to me. I've been trying to figure out what a pickup table is from context, but I'm stuck there too.
Some example fields from the documentation:
Country | Entity | Represents country. | Reference to the pickup table “Countries”.
State | Entity | Represents lifecycle State of the entity. For example, possible states of the Work Itemobjects can be Draft, Active, Cancelled, Completed, On Hold. Value is a reference to Statepickup table.
These examples make me think it's just a static list (which doesn't fit their given definition of pick up table), but if so the list/table is not provided to the user so I'm not sure how I would make use of it. If it does in fact refer to a static list, I'm going to have to try to coax them into giving me the tables.
I can't find a definition of pickup table online, so if anyone here knows it would help greatly.
My guess is that it's another name for a junction table, or association table. There are only foreign keys that refer to primary keys in other tables.
Pickup tables are picklists. The values of the picklist are stored in mini-tables (not really sure why but doesn't seem to be that important).
The work item state example is an example of a picklist.
I have one question which can be best described by the following scenario.
Suppose I have three tables BaseCategory,Category and products. If i am thinking in terms of RDBMS then the relationship amoung these tables are
1- One BaseCategory has Many categories
2- One Category has Many Products.
Now i am thinking to convert it into HBase. can anybody help me how to map these relations into HBase?
You'd probably have each row represent a supercategory/category pair (encoded with a separator, e.g. MySuperCategory:MyCategory, and a column family named "products" with a column for each product in that category.
This would allow you to very quickly retrieve all of the items in a given supercategory/category pair, and with some de-duplication all of the items in a supercategory.
Disclaimer: I'm an SQL newb, just discovering the great possibilities of sqlite embedded in applications.
I'm designing a small database for an application that primarily handles data storage for plotting. Say I have several instrument data tables (one for each type of instrument) with a column for each data field, such as pressure, temperature, humidity, etc. I would like to join these data tables, pull out the column names, and assign a more human-readable column "description" made available to the user for selecting the independent/dependent variables for plotting. Getting the column names in sqlite is easy enough, but I'm not sure if I should store the resulting names (and longer descriptions) as another table in the db or in a list of some sort in the application. If it were another table in the db, I think I would have to store the column name as a string... unless there is some way to reference a column in SQL? I'm not sure if there is a foreign key equivalent for columns, or if this is just a sign of bad database design needing restructuring.
Thanks for any suggestions, stack overflowers.
There are ways to do introspection in SQL and pull out table and column names, but you probably don't want to do it that way, and the implementation details of that are highly dependent on your particular RDBMS.
Since the human-readable column name is a display detail, and likely a static value, keep it out of the database and somewhere in the display/rendering portion of your app. (There are exceptions to this, such as if you want the column name to be customizable per-user.) You can keep a hash or dictionary which defines a human-friendly name and uses the actual database column name as its key. This setup can be handy for saving other settings for the display of the column, such as datatype, precision to display (if a number), etc.
What you are after is sometimes called a 'data dictionary'. If the DBMS does not provide annotation facilities, then you will need to simulate them, and that is likely to include creating a table with table names as well as column names in it. It is perfectly reasonable to do that.
Be aware of the difficulties with keeping track of changes to table names and added or deleted columns; the built-in facilities only keep track of the data in the system catalog (the 'data dictionary' information that the DBMS needs to track what goes on) and will not keep track of what is in your table.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
It it ok to have a table with just one column? I know it isn't technically illegal, but is it considered poor design?
EDIT:
Here are a few examples:
You have a table with the 50 valid US state codes, but you have no need to store the verbose state names.
An email blacklist.
Someone mentioned adding a key field. The way I see it, this single column WOULD be the primary key.
In terms of relational algebra this would be a unary relation, meaning "this thing exists"
Yes, it's fine to have a table defining such a relation: for instance, to define a domain.
The values of such a table should be natural primary keys of course.
A lookup table of prime numbers is what comes to my mind first.
Yes, it's certainly good design to design a table in such a way as to make it most efficient. "Bad RDBMS Design" is usually centered around inefficiency.
However, I have found that most cases of single column design could benefit from an additional column. For example, State Codes can typically have the Full State name spelled out in a second column. Or a blacklist can have notes associated. But, if your design really does not need that information, then it's perfectly ok to have the single column.
I've used them in the past. One client of mine wanted to auto block anyone trying to sign up with a phone number in this big list he had so it was just one big blacklist.
If there is a valid need for it, then I don't see a problem. Maybe you just want a list of possibilities to display for some reason and you want to be able to dynamically change it, but have no need to link it to another table.
One case that I found sometimes is something like this:
Table countries_id, contains only one column with numeric ID for each country.
Table countries_description, contains the column with country ID, a column With language ID and a column with the localized country name.
Table company_factories, contains information for each factory of the company, including the country in Wich is located.
So to maintain data coherence and language independent data in the tables the database uses this schema with tables with only one column to allow foreign keys without language dependencies.
In this case I think the existence of one column tables are justified.
Edited in response to the comment by: Quassnoi
(source: ggpht.com)
In this schema I can define a foreign key in the table company_factories that does not require me to include Language column on the table, but if I don't have the table countries_id, I must include Language column on the table to define the foreign key.
There would be rare cases where a single-column table makes sense. I did one database where the list of valid language codes was a single-column table used as a foreign key. There was no point in having a different key, since the code itself was the key. And there was no fixed description since the language code descriptions would vary by language for some contexts.
In general, any case where you need an authoritative list of values that do not have any additional attributes is a good candidate for a one-column table.
I use single-column tables all the time -- depending, of course, on whether the app design already uses a database. Once I've endured the design overhead of establishing a database connection, I put all mutable data into tables where possible.
I can think of two uses of single-column tables OTMH:
1) Data item exists. Often used in dropdown lists. Also used for simple legitimacy tests.
Eg. two-letter U.S. state abbreviations; Zip codes that we ship to; words legal in Scrabble; etc.
2) Sparse binary attribute, ie., in a large table, a binary attribute that will be true for only a very few records. Instead of adding a new boolean column, I might create a separate table containing the keys of the records for which the attribute is true.
Eg. employees that have a terminal disease; banks with a 360-day year (most use 365); etc.
-Al.
Mostly I've seen this in lookup type tables such as the state table you described. However, if you do this be sure to set the column as the primary key to force uniqueness. If you can't set this value as unique, then you shouldn't be using one column.
No problem as long as it contains unique values.
I would say in general, yes. Not sure why you need just one column. There are some exceptions to this that I have seen used effectively. It depends on what you're trying to achieve.
They are not really good design when you're thinking of the schema of the database, but really should only be used as utility tables.
I've seen numbers tables used effectively in the past.
The purpose of a database is to relate pieces of information to each other. How can you do that when there is no data to relate to?
Maybe this is some kind of compilation table (i.e. FirstName + LastName + Birthdate), though I'm still not sure why you would want to do that.
EDIT: I could see using this kind of table for a simple list of some kind. Is that what you are using it for?
Yes as long as the field is the primary key as you said it would be. The reason is because if you insert duplicate data those rows will be readonly. If you try to delete one of the rows that are duplicated. it will not work because the server will not know which row to delete.
The only use case I can conceive of is a table of words perhaps for a word game. You access the table just to verify that a string is a word: select word from words where word = ?. But there are far better data structures for holding a list of words than a relational database.
Otherwise, data in a database is usually placed in a database to take advantage of the relationships between various attributes of the data. If your data has no attributes beyond its value how will these relationship be developed?
So, while not illegal, in general you probably should not have a table with just one column.
All my tables have at least four tech fields, serial primary key, creation and modification timestamps, and soft delete boolean. In any blacklist, you will also want to know who did add the entry. So for me, answer is no, a table with only one column would not make sense except when prototyping something.
Yes that is perfectly fine. but an ID field couldn't hurt it right?