I have a string that is written out like an XML file. An example would look like this:
string = <Employees><EmployeeId>1</EmployeeId>< ... ></Employees>
I am saving this in a table because I wanted to audit changes, but I didn't want to have multiple tables for different audits. This is because it would record changes to things other than employees. So using an XML style string in the database seemed like a good suggestion.
Now to the real business. I want to check to make sure that there were actually changes to the employee because one could go into the edit page, change nothing, and click save. As of right now, the data would write to the DB and just clutter it up with non-changed data.
I'd like to be able to check if the XML styled string that is going to be saved is on the database, so if <employees><employeeid>###</employeeid> == "changes" and then see if the whole string equals the other. Basically, check the employeeId first because that won't change, and then check the string as a whole to see if there is any difference. I would have just checked the first n numbers, but the id number could have a length of 1 to 3.
Also, because it is styled as XML, is there an easy way to convert it to read it like an XML file and check that way?
Storing arbitrary data in a column is a form of denormalization. You can't really do much with it at a database level. However, SQL Server does have an XML column type. Entity Framework doesn't support mapping to/from an XML column, so it will simply treat your XML as a standard string. With this column type, though, you can write actual SQL queries against your XML using XPath expressions.
Your best bet, then, is to type your column as XML, and then write a stored procedure that performs the query you need. You can then utilize this stored procedure with Entity Framework.
For more information on the XML column type see: https://msdn.microsoft.com/en-us/library/ms190798(SQL.90).aspx
Related
In my project (I am using azure storage) I have some data that I want to translate. I have the resource system in place for translations. I have a table in cloud which has name property. I want to translate it somehow.
One option is to create all the entries in database for each language which I don't prefer as it would create a lot entries along with the name.
Is there a smart way to use the resx mechanism I have in place?
So the table has multiple properties and one is name. Name could be anything like Mud, rock etc. Now I want to translate Mud into different language. Something like Texts.Mud would return me the correct value.
But lets say I get data like this
var data = some query;
string translatedName = Texts.data[0].name; // this won't work
You should instead add more columns in the database, each for a different language and select the column based on the user language.
Other solution is to have a transaltion mechanism (a custom class for example), where you pass the original database result (say data[0].name) to a query and it returns the translated value for you.
I would like to store a c# object in SQL server. I thought about the following options:
Read object byte memory stream and save them into the database (but
not readable in sql)
Json, readable, easy to convert but what data type? (only a datatype for sql 2016)
XML, a bit less readable, easy to convert, there is an XML dataType
What's the best practice to store a C# object in a sql column and why?
I am using SQL 2014, so I think option 3 is the best?
Edit:
Note: it's not data to query, I just want to load a object which I have cached into a c# object in memory. And perform some logic on that in c#. It just takes a while to get the data from another database, therefore I save all my data in a custom object. Therefore I don't think I should use ORM
If it's just to throw in a database to read back at some point later by a key, then go with (2) and just use an nvarchar(max) field type.
If it's data to query, then you should probably design a schema to match and use an ORM.
If you are more positive towards option B, then you can store json-serialized string of any object[or datatype] in sql server as NVARCHAR(MAX) field.
And when you want to read it you can easily de-serialize that string in original format.
e.g.
Demo d1=new Demo();
//store this json into database.
string json= JsonConvert.SerializeObject(d);
// Now while reading fron db
Demo d2= JsonConvert.DeserializeObject<Demo>(json);
I'd go for JSON serialisation, it's just text, so when storing things like "user profile settings" or other types of structural data you're covered as you can read and write JSON in any language. Now SQL server has also understood this, like the XML support that was such a hype 8-10 years ago one can now store JSON with a good deal of TSQL support for those that need to update the data, like when you need to fix all updates for all user where...
anyway, have a look at the article. JSON in SQL Server 2016-2017
When going to and from JSON you should test your properties as some data types might not convert back and forward nice depending on things like regional specific settings like date and decimal values.
I have an ADO.NET DataSet that is persisted as XML. I need to add to it a list of cities and allow the user to select which city they're in. The selection has to be stored in the XML file along with the rest of the data.
This seems like a perfect use for DataSet.ExtendedProperties. However, it turns out that, in order for the extended properties to get written to the XML, I need to use XmlWriteMode.WriteSchema and XmlReadMode.ReadSchema, which adds the entire schema of the DataSet to the XML file just so it can add a single attribute, msprop:CityID.
My DataSet is strongly typed and its schema is hard-coded by the designer, so I really don't need to store the schema in the XML, which can lead to run-time errors.
So my question is, what's the best way to add the selected city to the DataSet itself. For example, using another table called SelectedCity, or using a Boolean column in the City table called IsSelected.
The SelectedCity table will always need to contain exactly one row, and the IsSelected column will need to contain true in exactly one row and false in all the others, and I don't know how to enforce such constraints in ADO.NET.
This seems like a fairly common scenario. What's the recommended way to code it?
If the relation is 1 to 1 put the field in the parent, but if a user can have various 1 to N put in another table. Sorry for my english.
Suppose i have one table that holds Blogs.
The schema looks like :
ID (int)| Title (varchar 50) | Value (longtext) | Images (longtext)| ....
In the field Images i store an XML Serialized List of images that are associated with the blog.
Should i use another table for this purpose?
Yes, you should put the images in another table. Having several values in the same field indicates denormalized data and makes it hard to work with the database.
As with all rules, there are exceptions where it makes sense to put XML with multiple values in one field in the database. The first rule is that:
The data should always read/written together. No need to read or update just one of the values.
If that is fulfilled, there can be a number of reasons to put the data together in one field:
Storage efficiency, if space has proved to be a problem.
Retrieval efficiency, if performance has proved to be a problem.
Schema flexilibity; where one XML field can eliminate tens or hundreds of different tables.
I would certainly use another table. If you use XML, what happens when you need to go through and update the references to all images? (Would you just rather do an Update blog_images Set ..., or parse through the XML for each row, make the update, then re-generate the updated XML for each?
Well, it is a bit "inner platform", but it will work. A separate table would allow better image querying, although on some RDBMS platforms this could also be achieved via an XML-type column and SQL/XML.
If this data only has to be opaque storage, then maybe. However, keep in mind you'll generally have to bring back the entire XML to the app-tier to do anything interesting with it (or: depending on platform, use SQL/XML, but I advise against this, as the DB isn't the place to do such processing in most cases).
My advice in all other cases: separate table.
That depends on whether you'd need to query on the actual image data itself. If you see a possible need to query on certain images, or images with certain attributes, then it would probably be best to store that image data in a different way.
Otherwise, leave it the way it is.
But remember, only include the fields in your SELECT when you need them.
Should i use another table for this purpose?
Not necessarily. You just have to ensure that you are not selecting the images field in your queries when you don't need it. But if you wanted to denormalize your schema you could use another table and when you need the images perform a join.
My application has dozens of ComboBoxes filled with lists of values.
I wonder what is the best way to store these values in the DB since the user can add/remove :
Store in XML in Sql Server ?
Store in a text file on the server ?
any best practice ?
Thanks
John
I would keep track of them in a table on SQL server. If a user can define each field, then you simply need a table with a field name, value, and userid. Then you can extrapolate all of it from there.
Of course, you would want to use a key of some kind linked to a table that defines each type of field possible, if needed.
One row per key/value (combobox) should do the trick.
Another option to consider is to serialize your form in a json string that you'll store in a table in the SQL server DB. That way, you'll only have one entry per user to read. Then, you can deserialize the json string in an object that retains the properties of each control.
The big advantage of doing it this way is that if your form changes (and changes do happen!) you won't have to modify the data layer (ie. table definition + query).