I have an Informix database that I really would have liked an 'enum' field for. Being that Informix (At least in the version I am constrained to) has no built-in enum type I used some Google-Foo to find out that I could constrain a VARCHAR field to only allow certain values like so:
ALTER TABLE table ADD CONSTRAINT CHECK (type IN ('type1', 'type2', 'type3'));
This seems to work well. Now I need to connect to the database from a Perl script that checks user input against those valid values. I can of course check them in code and make sure my code knows what the values are that the database requires, but I wondered if there is any way I could have my script query the constraint on the database therefore if I need to Add/Remove a valid input at a later time I could just alter the constraint and the processing code would adapt.
Any suggestions would be greatly appreciated.
If you encapsulate you database access in a DBIx::Class schema, you gain this kind of validation "as a bonus".
A simple way of generating the schema from a pre-existing database is by
dbicdump.
Related
i wanted to create via Excel or Oracle a database for a Storage room that is filled with all kinds of Computer parts and stuff.
I never created something like that, so i wanted to know if you could help me out giving me an advice how to create a database for a beginner
It should be possible to insert and remove parts or even update them
Hope my question is readable and understandable.
Thanks
A simple option to do that - not only the table so that you could write your own DML statements (to insert, update or delete rows) - but to create a nice application - is to use Oracle Application Express (Apex).
Depending on database version you use, it might already be installed by default. If not, ask your DBA to install it.
Alternatively, create a free account on apex.oracle.com; you'll get limited space (more than enough to do what you want to do).
In Application Builder, use the Excel file you have as a "source" which will then be used by Apex's wizard to create a table in the database, as well as application, true GUI which works and looks just fine.
If you don't have anything at all, not even an Excel file, well ... that's another problem and requires some more work to be done.
you have to know what you want (OK, a storage room)
is a single table enough to contain all information you'd want to collect?
if so, which columns (attributes) do you want to collect?
if not (for example, you'd want to "group" items), you'd need at least two tables which will be related to each other by the means of master-detail relationship, which also means that you'll have to create a foreign key constraint
which datatypes are appropriate for certain attributes? You wouldn't store item names into number datatype, right? Nor should you put dates (when item entered the storage room) as a string in varchar2 column, but into a date datatype column
etc.
Basically, YMMV.
My application has a database table that is used to record the attendance of employees. And the column attedance_status has only three possible values - "present", "absent", "on_leave", and NULL as default.
How do I add it to the database? So far I have come up with two possible ways.
Create another table attendance_status with status_id and status_value and add the above values to it. And then use the id in the application for all SQL queries.
Probably the bad way. Hardcode the values (maybe in a config file) and use it throughout the app's SQL queries.
Am I missing the right way? How should this be approached?
Either will work, but Option 1 will give you flexibility in the event that the requirements change and is the standard data model. I would, however, name my columns a little differently. I would have id, value, name. Then the references become attendance_status.id and attendance_status.value. The third column is available for use in displays or reports or whatever. value is on_leave and name is On leave.
Option 2 works provided the data input point is totally closed. If someone codes new functionality there is the risk that he or she will invent something different to mean the same thing like onLeave.
I am new to SQL Server, coming from a MySQL background. I am trying to migrate a MySQL table that contains several fields defined similarly to the following one:
"FavoriteColors" SET('Red','Blue','Dark Purple', 'Green') DEFAULT NULL,
Basically, they are multiple-choice questions. When entering these fields in a form, the user will be able to select one or more of them.
When looking for a SQL Server equivalent to this definition, I have seen that many people create an extra table for the different choices, and then a lookup table to connect the two previous ones. Knowing that there are several multiple-choice fields like this one, it seems a pretty complicated solution for such a simple definition. Is this really best practices, or do you recommend an alternate solution? Of course, I can use BIT fields for each of the choices, but again, it seems to me that SQL Server probably has a simpler, better organized solution for this.
Thanks a lot!
You can create user-defined type and create a rule for this data type. This enables you use this new data type everywhere in your database
Here is the code, please execute step by step
CREATE TYPE [dbo].[Color] FROM [nvarchar](40) NULL
CREATE RULE ruleColor
AS
(#phone='Red') OR
(#phone='Black')
GO
EXEC sp_bindrule 'ruleColor', 'Color'
I hope it helps,
I am using entity framework to insert details into the database where I have a column varchar(50).
when I am trying to insert some value more than 50 length it gives me an error string or binary data would be truncated.So ., for safe side I just changed it to varchar(100).
Now can someone let me know is this the only solution to change the value in the Db or do we have any alternatives.......
I read an article http://sqlblogcasts.com/blogs/danny/archive/2008/01/12/scuffling-with-string-or-binary-data-would-be-truncated.aspx
But how can I use such things in c#. I appreciate any suggestions from you.........
Thanks
Depending on what type of input field you're dealing with, using varchar(max) could be an option.
But as previously pointed out, it really boils down to what your business requirements are.
Well, first of all, obviously you cannot insert a string longer than 50 in a varchar(50).
So you have two options depending on your requirement:
change the database (as you have found out) and make sure that all code 'upstream' will be able to tackle the longer data
add some validations or restrict user input so that you will never get a string that is longer
Well, there's a third and that is cut off the string without telling the user but I would not do that.
So it depends on your business requirement what to do. But I would not do any 'tricks' like in the article you suggested
You should set the field length in the db to whatever is a reasonable length and you should prevent users from entering values that does not fit within that length.
1-when database table Alter when issue generated
2-First Backup table schema and data then delete table when re create table then run code .. working fine.
Is there some kind of mechanism in SQL Server to allow Enumerated type like functionality?
For example, if I have a column Called "UpdateStatus" it usually gets setup with single letter values like so:
D
X
U
I
This could equate to a lot of things. That leads to confusion. The alternative is to have it be a string column like this:
Downloaded
Deleted
Updated
Initialized
But that has its own problems. Eventually someone is going to write something like this: where UpdateStatus = 'Initalized' (spelled wrong). Plus I hear that keying off of strings is not all that performant.
So, is there any kind of enumerated type for SQL Server that can help out with this? Basically I am looking for compile time checking that a value being compared (ie "Initialized") is part of a list of values.
I am using SQL Server 2008.
Why not have lookup table that contains the code and description. Creating a foreign key to this lookup table will result in only valid codes being used.
Besides lookup tables (FKs), in simple cases, you can use check constraints:
CREATE TABLE my_table (
UpdateStatus VARCHAR2(11)
CHECK( UpdateStatus IN ('Downloaded', 'Deleted', 'Updated', 'Initialized'))
)
The only way that I've seen this done is by using a UDF to evaluate whether or not the enum's string representation is valid. It's slow, it's painful, and usually not worth it, but at least you have a way to fail loudly instead of silently.
And remember, you can't RAISERROR in a UDF so you have to cause an intentially cause an error, and log separately.
Ultimately, at the moment, the 'perfect' solution to the problem would be to approach from the other side -- you can achieve this mentality with a code-first ORMs, which would allow you to use native enums in your code, and the corresponding SQL lookups will be created properly in migration.
Here's to hoping we get enums soon, we're feeling a little left out.