Say if I have a column in database which can accept any one value of the enum that is defined in my C# code.
There is a usual way to make it be available to the database to store it in a database table and refer it from there.
But sometimes you don't want to store the enum in the database but just want to maintain it in the code, for these cases I have come up with the solution in my project to have a view which will return the values of enums so that we do not have to hard code it in the database, so having something like this in the database
CREATE VIEW ENUM.ValidationFailReasonTypes
AS
SELECT 1 AS [FormLevel], 2 AS [GridLevel]
For enum
public enum ValidationFailReasonTypes
{
FormLevel = 1,
GridLevel = 2
}
So just wanted to ask is it a good idea to do like this or is there some better way to handle this case when we don't want to store enum in the database?
It all depends.
Old school database folk like me want you to build validity checks into your data model. See this question for how you would do that. You end up with a nice, self-documenting schema, which guarantees that your application can only contain valid entries for ValidationFailReasonTypes.
An alternative view is that the database is just the storage mechanism, and it's perfectly OK for the application to be the guarantor of data validity, especially if it has lots of unit tests. In this case, you use an ENUM in you C#, write unit tests to validate that the entries match your expectations, and accept the fact your database table has an integer column which could contain lots of values, but the application limits it to (1, 2).
I think it's important to pick one approach and stick to it. Your solution - if I understand it correctly - is a bit of both.
In general, I'd use an enum for values that are not going to change without a new release of your application, usually because you're enabling some new functionality.
I'd expect to use a database entry for something that can change in the business domain independently of your application's release. "Grid level" and "form level" feel like features in your application, so I think an enum is okay.
The entire reason for an enum is consistency, clarity, and ease of use when coding. I would think you would want that sort of clarity and consistency on the database side as well. If you persist an enum value to the database, you absolutely should have referential integrity on the column and a corresponding definition table. The view saves you nothing in my opinion.
Create a table and add referential integrity to the field even if it only has two rows for all eternity.
Related
I'm developping an application and I often ask myself the same question.
For example, I have many types of user and in a form used to create a user, there is a dropdown to specify which type of user.
The best way to populate this dropdown is to store values in a database's table ? If I do this, when I develop I want to test type of user and I have only an int. But I thing it's a better practice to test with enum. So I create enum but I feel it's a bad practice because I have to keep database and enum synchronized.
Another question is about localization. If I put values in database, I can't use resource file.
Could you tell me good pratices about this ?
Thanks
in your situation - the database would be the best practice here especially if its dynamic data. enum is for those values which are rarely to change, maybe once in a while but not on a frequent basis. you may have new entries entered in the database regularly especially for things like cascading drop down lists.
database certainly is the way to go in your situation. Enums are there for those times where they are just a set standard and rarely to change, for example:
Mr.
Miss.
Mrs.
Ms.
Dr.
you would have these in enums as they will never really change. on the other hands if store departments are to be changed or renamed, database would be the place to store such entries.
I strongly disagree with using enums for this kind of functionality, for basically two reasons:
Enumeration values have no behaviour, so compromise good OOP. A good class has data + behaviour, so enumeration members are not sufficiently specialised to represent the concept they are named for. The logic concerning this domain object lives somewhere else other than the entity that bears its name, which I dislike.
Enumerations are meant to convey ordinality, so DaysOfWeek is a good usage (except that which day of the week is 'first' varies depending on culture, but that' nitpicking) because the enumeration denotes the order of its members. In your case, does it make sense to say that a particular value is the 'first' user type, the second value is second, and so on? Probably not.
My first question would be - do you actually use the user type anywhere in the database?
If the answer is no, everything is easier, since you can simply use an enum and be done with it.
Otherwise, you probably should have a user type table as well, to get to use foreign keys properly.
Personally, I use manual ID for these - autogenerated keys can make a mess of your attempts to synchronize code and database. Ideally, if your ORM allows it, you could have the code-database synchronization automatic - either through code generation, or through automatic database data update. If you can't, though, manually coding the enums (or some kind of pseudo enum) should still be a lot nicer in the code.
As for localization, your options are completely the same. Just use a resource key like "UserType-XXX", where XXX is the database ID of the type. If you want, you can also store the localized values in the database. Just do whatever feels the best for your application.
I'm trying to figure out which is the the "correct" way to do this. I have a bunch of lookup tables in my database and would like to place an enum on top of those values so, when coding, it's easier to read (as well as not use hard-coded values).
I'm wondering if I should generate my table values based on an existing enumeration or if I should generate my enumeration from my table's values.
EDIT
Based on the first couple of comments, here are some clarifications:
Frequency of changes to the values could be rather frequent as they are intended to be rather dynamic. That being said, a compile will be necessary before adding any of these either way, because the enumeration needs to be updated to expose the new values.
The main reason for this need is because we don't want to tie people down to a specific list of values, we would like the applications to have the ability to add new entries as and when they need to.
In the past, we have generated the data from enumerations, but I'm second guessing myself
We usually generate enums from the database. We use CodeSmith, which allows us to create project files that can easily regenerate the enums as needed.
We've gone the other way occasionally, usually for reporting purposes (when existing enum values are persisted).
And, of course, we have enums whose values are never persisted.
In general the only reason to generate enums from the database is if code needs to make decisions based on them. If you just want to populate a ComboBox and persist the user's choice, don't generate an enum.
Obviously making decisions based on enums (or strings) whose values can change is fragile. You may want to consider including expiration dates (or "from" and "through" dates) in your database schema, so that existing values are not deleted. Filter expired values when populating UI selectors. This also makes it easier to have referential integrity.
As always in C#, you have to be aware that enum values may fall outside of the expected range. Include a default on your switch.
We came up with helper classes for creating cached lookup lists that make these easier to use.
I'm not advocating going down this route. If you have to, this is how we did it.
There's also a third option in that you have a explicit model which describes the schema in the level of detail you require and then you generate both data & schema from that model.
Regarding your question I think what you should do is thinking about the problem in your context and list pros/cons for you with each alternative and decide on what makes most sense for you and your business.
I have worked worked with all three strategies for different applications, the one I personally prefer is having an explicit model buts depending on the context.
Sorry for being fuzzy but I think for these kind of questions there's real golden rule which always applies in all cases.
I'm wondering if the following DB schema would have repercussions later. Let's say I'm writing a place entity. I'm not certain what properties of place will be stored in the DB. I'm thinking of making two tables: one to hold the required (or common) info, and one to hold additional info.
Table 1 - Place
PK PlaceId
Name
Lat
Lng
etc... (all the common fields)
Table 2 - PlaceData
PK DataId
PK FieldName
PK FK PlaceId
FieldData
Usage Scenario
I want certain visitors to have the capability of entering custom fields about a place. For example, a restaurant is a place that may have the following fields: HasParking, HasDriveThru, RequiresReservation, etc... but a car dealer is also a place, and those fields wouldn't make sense for a car dealer.
I want to support any type of place, from a single table (well, 2nd table has custom fields), because I don't know the number of types of places that will eventually be added to my site.
Overall goal
On my asp.net MVC (C#/Razor) site, where I display a place, it will show the attributes, as a unordered list populated by: SELECT * FROM PlaceData WHERE PlaceId = #0.
This way, I wouldn't need to show empty field names on the view (or do a string.IsNullOrWhitespace() check for each and every field. Which I would be forced to do if every attribute was a column on the table.
I'm assuming this scenario is quite common, but are there better ways to do it? Particularly from a performance perspective? What are the major drawbacks of this schema?
Your idea is referred to as an Entity-Attribute-Value table and is generally bad news in a RDBMS. RDBMSes are geared toward highly structured data.
The overall options are:
Model the db further in an RDBMS, which is most likely if someone is holding back specs from you.
Stick with the RDBMS, using XML columns for the data whose structure is variable. This makes the most sense if a relatively small portion of your data storage schema is semi- or un-structured. Speaking from a MS SQL Server perspective, this data can be indexed and you can perform checks that your data complies with an XML schema definition.
Move to a non-relational DB such as MongoDB, Cassandra, CouchDB, etc. This is what a lot of social sites and I suspect blog sites run with. Also, it is within reason to use a combination of RDBMS and non-relational stores if that's what your needs call for.
EAV gets to be a mess because you're creating a database within a database and lose all of the benefits a RDBMS can provide (foreign keys, data type enforcement, etc.) and the SQL code needed to reconstruct your objects goes from lasagna to fettuccine to spaghetti in the blink of an eye.
Given the information that's been added to the question, it would seem a good fit to create a PlaceDetails column of type XML in the Place table. You could also split that column into another table with a 1:1 relationship if performance requirements dictate it.
The upside to doing it that way is that you can retrieve the data using very simple SQL code, even using the xml data type's methods for searching the data. But that approach also allows you to do the more complex presentation-oriented data parsing in C#, which is better suited to that purpose than T-SQL is.
If you want your application to be able to create its own custom fields, this is a fine model. The Mantis Bugtracker uses this as well to allow Admins to add custom fields to their tickets.
If in any case, it's going to be the programmer that is going to create the field, I must agree with pst that this is more a premature optimization.
At any given time you can add new columns to the database (always watching for the third normalization rule) so you should go with what you want and only create a second table if needed or if such columns breaks any of the normal forms.
What would be the best database/technique to use if I'd like to create a database that can "add", "remove" and "edit" tables and columns?
I'd like it to be scaleable and fast.
Should I use one table and four columns for this (Id, Table, Column, Type, Value) - Is there any good articles about this. Or is there any other solutions?
Maybe three tables: One that holds the tables, one that holds the columns and one for the values?
Maybe someone already has created a db for this purpose?
My requirements is that I'm using .NET (I guess the database don't have to be on windows, but I would prefer that)
Since (in comments on the question) you are aware of the pitfalls of the "inner platform effect", it is also true that this is a very common requirement - in particular to store custom user-defined columns. And indeed, most teams have needed this. Having tried various approaches, the one which I have found most successful is to keep the extra data in-line with the record - in particular, this makes it simple to obtain the data without requiring extra steps like a second complex query on an external table, and it means that all the values share things like timestamp/rowversion for concurrency.
In particular, I've found a CustomValues column (for example text or binary; typically json / xml, but could be more exotic) a very effective way to work, acting as a property-bag for the additional data. And you don't have to parse it (or indeed, SELECT it) until you know you need the extra data.
All you then need is a way to tie named keys to expected types, but you need that metadata anyway.
I will, however, stress the importance of making the data portable; don't (for example) store any specific platform-bespoke serialization (for example, BinaryFormatter for .NET) - things like xml / json are fine.
Finally, your RDBMS may also work with this column; for example, SQL Server has the xml data type that allows you to run specific queries and other operations on xml data. You must make your own decision whether that is a help or a hindrance ;p
If you also need to add tables, I wonder if you are truly using the RDBMS as an RDBMS; at that point I would consider switching from an RDBMS to a document-database such as CouchDB or Raven DB
Assume I have a declared a datatable and to this datatable I have assigned a result that gets returned from calling a stored procedure, so now, my datatable contains something like the following when accessing a row from it:
string name = dr["firstname"];
int age = (int)dr["age"];
if firstname is changed to first_name and age is removed, the code will obviously break because now the schema is broken, so is there a way to always keep the schema in sync with the code automatically without manually doing it? Is there some sort of meta description file that describes the columns in the database table and updates them accordingly? Is this a case where LINQ can be helpful because of its strongly typed nature?
What about good old fashioned views that select by column name, they always output the columns with the specified names in the specified order. If the table underneath needs to change, the view is modified if necessary but still outputs the same as it did before the underlying table change - just like interfaces for your objects. The application references the views instead of the tables and carries on working as normal. This comes down to standard database application design which should be taught in any (even basic) data architect course - but I rarely see these actually used in business applications. In fact, the project I'm currently working on is the first where I've seen this approach taken and it's refreshing to actually see it used properly.
Use stored procs, if your table changes, modify the stored proc so the output is still the same - used in a similar manner to shield the application from the underlying table thus insulating the application from any table changes. Not sufficient if you're looking to do dynamic joins, filters and aggregates where a view would be more appropriate.
If you want to do it application side, specify the names of the fields you're querying right in the query rather than using "select *" and relying on the field names to exist. However, if the field names on the table change, or a column is deleted, you're still stuck, you've gotta modify your query.
If the names of fields will change, but all of the fields will always exist, the content of those fields will remain the same and the fields will remain in the same order, you could reference the fields by index instead of by name.
Use an object relational mapper as others have specified, but I don't think this necessarily teaches good design rather than hopes the design of the framework is good enough and appropriate for what you're doing, which may or may not be the case. I'm not really of the opinion this is a good approach though.
About the only way to prevent this is through the use of Stored Procedures which select the columns and rename them to a standard name that is returned to your application. However, this does add another layer of maintenance to the database.
This was the reason ORM solutions such as NHibernate were created.
That or a code generator based on the database schema.
Why would you not want to change the code? If age is removed why would you want to still attempt to grab it in your code?
What Linq does is try to keep all the business logic in one location, the source code, rather than splitting between Database and Source Code.
You should change the code when the data columns are removed.
As you can perceive from all the answers given, what you are looking for doesn't exist. The reason for this is that you should remember programs are essentially data processing routines, so you can't change your data without changing something else in the program. What if it isn't the name of the column but it's type that's changing? Or what would happen if the column was deleted?
In sum, there's no good solution for such problems. Data is an integral part of the application - if it changes, expect at least some work. However, if you expect names to change (the database isn't yours, for example, and you have been informed by the owner that it's name might change in the future), and you don't want to re-deploy the application because of that, alternatives to recompiling your source code which, as stated in the other answers, include:
Use Stored Procedures
You can use stored procedures to provide data to the application. In the case of the proposed change (renaming a column), the DBA or however was in charge of the database schema should change the stored procedure as well.
Pros: No need for recompilation due to minor changes in the database
Cons: More artifacts that become now part of the application design, application understanding is blurred.
Use a Mapping File
You can create a mapping file that gives you the name that your application expects a certain column to have and the actual name the column has. Such are very inexpensive and easy.
Pros: No need for recompilation due to minor changes in the database
Cons: Extra entity (class) in your design, application understanding is blurred, you need to re-deploy the mapping file on change.
Use column position instead of column name
Instead of referencing the name of the column, use a positional argument (dr[1]).
Pros: Keeps you safe from name changes.
Cons: Everything else. If you table changes to accommodate more data (new column) there's a chance the numbering of columns will also change, if any of the columns is deleted you also will have a numbering problem, etc.
But a suggestion. Instead of accessing the column direct through a literal, use constants with some good naming standard. So
string name = dr["firstname"];
int age = (int)dr["age"];
Becomes
private const string CUSTOMER_COLUMN_FIRST_NAME = "firstname"
private const string CUSTOMER_COLUMN_AGE = "AGE"
string name = dr[CUSTOMER_COLUMN_FIRST_NAME];
int age = (int)dr[CUSTOMER_COLUMN_AGE];
This doesn't solves your problem, but it enables you to add better meaning to the code (even if you decide to abbreviate the constant's name) and make changing the name more easily, since it's centralized. And, if you want, Visual Studio can generate a class (inherited from DataTable) that statically defines your database rows, which also make code semantics more clear.
Apparently you have to introduce another layer of abstraction between your database and your applicatoin. Yes, this layer can be Linq2Sql, Entity Framework, NHibernate or any other ORM (object relation mapping) framework.
Now about that 'automatically'... maybe this kind of small change (renaming a column) can be handled automatically by some tools/framework. But I don't think that any framework can guarantee proper handling of changes automatically. It many cases you will have to manually do the "mapping" between your database and that new layer, so that you can keep the rest of your application unaffected.
Yes, Use Stored procedures for all access, and alias the actual attribute names in the table for output to the client code... Then if actual column names in the table change, you just have to change the sql in the stored proc, and leave the aliases the same as they were, and the client code can stay the same
Is there a way to not break code if columns in a database change?
No
It is a very, very good thing that you can't do this (completely) automatically.
If the database changes such that an application feature is no longer valid, you don't want the application to continue to expose the feature if the database no longer supports the feature.
In the best case, you want database changes to cause your code to no longer compile, so you can catch the problems at compile time rather than run time. Linq will help you catch these kinds of issues at compile time and there are many other ways to increase the agility of your code base such that database changes can be somewhat quickly propagated through the entire code base. Yes, ORMs can help with this. While views and stored procedures may make the problem better, they may also make it worse by increasing the complexity and amount of code that needs to react to changes to columns in tables.
Using code generation of some sort to generate (at least some part of) your data layer is your best bet to getting compile time errors when your application and database get out of sync. You should probably also have unit tests around your data layer to detect as many run-time type inconsistencies as possible when it's difficult to find the errors at compile time (for example, things like size constraints on columns).
It won't help when "age" is removed, but if you know that the columns will always be returned in the same order - even if the names change, then you could reference them by column name, instead, like:
string name = dr[0];
int age = (int)dr[1];
Depending on your DB version, you could also check out a Data Access generator such as SubSonic.