I am trying to develop a modular web aap using asp.net mvc 4. My question is that what is the best place to store the user settings, configuration and user access. Whether it is good to store it in db or good to store it in xml file.
I would prefer to go with XML.
Advantages in XML file :
No need to access in your database server.(Which is contains valuable data)
Anybody can understand and change the settings. (No need to know about SQL)
Platform independent.
Disadvanges in XML file :
Need to backup the file. To overcome this problem, Have to maintain the changes by history (It is a best way to revert it back).
Related
I have an mvc4 application which use sql database as back end. I am using asp.net identity for authentication and authorization. I have a need to move some of the user settings/configuration from database to flat files. The current system stores user configuration in tables which we do not want to share with customers. This information must be maintained in flat files and be written in the directory where the code is executed. I need to come up with a .NET MVC prototype which can store/retrieve user configuration from a flat file.
Basically, I need that instead of using the database for authorization for storing and checking what users have access to what features etc. I can store in a flat file and load that into memory and use that to check for authorization for granting users access to different features.
Also when the admin changes users authorization stuff it should update the file.
Can anyone please suggest me some scenario.
You can look into using files as Resources in your code. Resources can be accessed, read and updated at run time. And these will not be exposed to the users.
Some links which might help.
https://stackoverflow.com/a/1533984/689625
https://stackoverflow.com/a/20908560/689625
https://msdn.microsoft.com/en-us/library/7k989cfy%28v=vs.90%29.aspx
I need a way to get all of the data out of an Ektron site in any format, that I can use to import it into a new CMS. To my eyes the database is completely obfuscated and I'm not finding any good resources. I would be happy for links, tips, videos, angels, magic lamps or companies that will do it on the cheep. Thanks in advance!
I do Ektron migrations of this nature regularly for my company and the problem with such migrations is that there really is no "standard". Every site has it's data structured quite differently and this will be especially true of ektron sites that rely on smartforms, or ones that have complex metadata or taxonomy relationships.
Your best bet will probably be to write a custom export tool to get your data into a format your target CMS can handle. If you are moving into another .net CMS, you might be well served by utilizing the ektron SOAP web services.
Two things that come to mind:
Perform database Backup (and Restore): "Backup" the Ektron database you are using and "Restore" it where you need it to go. Both of these actions can be performed using SQL
Server Management Studio with access to the filesystem on your
database server. This will restore ALL data EXACTLY as it was when
backed up. This is straight forward, but not flexible and I feel like this isn't
what you're looking for. If you want to treat "Ektron" like it's just any other database, then researching a more generic SQL Server Database "Dump" may be useful.
Perform content Export (and Import): Ektron provides a content export feature. This can be found in the Workarea under [Settings] > [Localization]. The purpose behind the export is to translate/localize content into another language and then import it back into the CMS, but... You aren't looking to localize your content as far as I can tell, but this export feature may still be of interest to you for whatever purpose you have in mind.
I am thinking when to use files instead of a database table for storage of data?
Example if you just have some backend settings, you could store them in a file..
Or is it best practise to have everthing in a DB?
I am using Rails as framework for my web applications.
If you are just looking to set some settings to be used in an app, why not just create a config or initializer file?
as part of an application I am trying to create, I am looking to data storage solutions. However, I have found many solutions that I can not quite directly apply to the position I am in.
Basically, I want to display in my app, a directory of the staff of my organization. About 100 or so individuals. I want to have generic attributes such as name, email, office#, etc.
However, my goal is to not end up with a static representation of the staff here! (people come and go, switch offices,etc.)
I am looking for the best way (if possible) to maintain a small database that I can administer, and if perhaps, something were to change to someone here, I can make the change and the change will be reflected accordingly.
Please help! I tried submitting my first app but got rejected because I relied on a webview to accomplish this task. This is an internship opportunity and my first real chance at development. Any help will be GREATLY appreciated.
Thanks!!!!!
The iPhone directory app can be used to store data in any format you want (xml, json or a proprietary format), because all you do is save a file. But if you choose to use the iPhone app directory to store data you have to write code to read the file (very simple to do) and parse the information (not so simple because the dificulty scales based on the information complexity).
SQLite is a tool to store structured data, providing you a set of tools to access and use the information. You don't need to parse the information, because SQLite does it for you by using transact sql queries.
By now, because you have a list of individuals, and these people are relationed to offices, I think you should use SQLite.
The Code Data is a object graph management, it's a tool to give you more options over data manipulation, and can make your life very easy if you have a lot of data and very complex data models. I don't think you need that for your particular problem, but I think you should learn it at some point.
UPDATE 1
You application will have something like:
A core database (sql server, oracle, my sql, etc) will hold your individuals information (your cloud database).
A web page (php, asp.net, etc) will display the core database information in json or xml format (your api).
A iphone app will download the information from the web page and store it in the local SQLite. (you have to decide when you will update the local sql lite, like when is opened, once a week, once a moth, twice a day, etc) (your local storage method).
Display the local SQLite individuals information in the app.
If we are migrating content from source Content Management System to Tridion, what is the best way of migrating customized metadata associated with the components(content) of source Content Management System into Tridion? Should we directly migrate it to the sql server or is there an option to migrate it in the form of some xml file, etc.?
Migrating directly into SQL Server is unsupported, and the entire system would be unsupported at that point, due to possible data consistency issues.
The most straightforward way is to read the data from the source system, and use the Tridion API to recreate the item.
If migrating metadata, some of the data would likely fit best into a taxonomy, which would mean you'd want to migrate the keywords / structure first, then tag the content as it came into Tridion.
You have a few options when migrating content into Tridion.
I can't understand from the above if you are talking about migrating to SQL server as an intermediate format, or directly into the Tridion database. Importing directly into the Tridion database is definitely not a supported solution, and could lead to unpredictable results.
You need to use the API, either the Core Service or the TOM.NET API (If you have Tridion 2011) or the old TOM API if not.
A popular approach is to export all content into an XML format that you can then process with a .NET application.
There's some good articles on migrating content into Tridion by Ryan Durkin here, and Nuno Linhares here.
As mention before, migrating directly into the Database is not an option if you are planning to use SDL Tridion as the final CMS.
Apart of the supported mechanism chosen for Migrate, play attention about how you are going to structure the metadata in the new CMS, as depending on the volume, structure, hierarchy, relation across metadata items the process can become complex.
Also play special attention at the Blueprint concept, as probably you can merge duplicated values from the old system into only one that is inherited.
Don't think only in how to put the metadata in the system, also how that Metadata will be used and maintained in the new CMS, in this case SDL Tridion
You can check also a recent post about Migration and plan Migration in general, in case adds some more information
Can we automate migrating to SDL Tridion?