I'm writing an app in vb.net and was wondering wath the best way to store/retrieve data was?
SQLite is a good choice.
I too use sql server to manage data for my desktop applicaton if it has to manage a large set of records.
But if an application is small then you can use ms-access or mysql as these database engine are light weight.
Try to use stored procedures as they can make ur execution faster
I would recommend the use of a relational database management system (and since you are using VB.NET, Microsoft SQL Server is probably going to be your best choice).
If a full-blown RDBMS is overkill for your application then you may want to read up on application settings.
It really depends on how much data you want to store. Little data could easily be stored in an XML based configuration file. If you have a lot of data to store, then XML will probably not provide the best performance. The more data you want to store, the more I would direct you to a database.
As for which database, it depends on how much data you want to store, how much work you want to do during installation, and how much control you have over the client's system. SQL Server or MySQL are good large databases, but if this is a small application, they might be overkill. Microsoft has a version of the SQL Server database that is file based (like MS Access). It doesn't allow stored procedures, but it can be embedded within your application (and its free). Its called SQL CE (Compact Edition).
SQLLite is good also, and you'll find a good amount of information to help you with that.
Just off the top, based on what you wrote and the wording, I would guess that you need something small, and quick. I would probably look at MS Access. There are ways you can use it without actually requiring that the user has access installed, its simple to setup, and the database is all in a single file, so installation is VERY easy.
Let me know how this works out for you,
Gabriel
If you just need to store simple configuration files, using the My.Settings namespace is a good way to go. Its very easy to use, and easy to access the data.
Related
well I need some suggestion from someone who already know what type of database for my application is the best.
I have tried to play with My.Settings type stored data and also MS-Access.
But I was wondering if I will made some Password manager app, and if my database will be installed in C drive of user, if someone will find the database, he could easy open it and see all passwords and datas,
Thank you for suggestion as I really need some help on this question.
I believe the answer here is "it depends"!
All databases have their advantages and disadvantages. The rule that applies here is that depending on the use you want to do, choose respectively.
The strengths of MySQL for example is low cost (free if you ever need community support), the ability to run on any platform but also significant flexibility in remote management.
The MS SQL is also very stable, provides storage processes, transactions and other powerful features. However less cost and simplicity of management with respect to MySQL. Of course Express Edition is a good and sufficient solution for many circumstances.
If you would like a more specific suggestion you must provide us with some more information and features for the application you want to develop.
I'm using the file database SQLite, with SQLite Studio (for Free) and it's great staff, if you don't need robust data storage solution.
Here are some recommendations, how to set password:
Password Protect a SQLite DB. Is it possible?
Pluses:
common SQL,
single file,
simple according to my mind.
and many more.
Database should be password protected
Use Encrypting Strategy to save password
May be below article help you
http://msdn.microsoft.com/en-us/library/ms172831.aspx
The dev tools for SQL in Visual Studio are great.
Is it possible to develop an app for Microsoft SQL Server, and then deploy a MySQL-compatible database instead?
The dev tools for Microsoft SQL Server are really nice (i.e. LINQ support), but a MySQL-compatible column database has better performance for huge datasets.
You would need to use MySql .net connector
http://dev.mysql.com/doc/refman/5.1/en/connector-net.html
With this, you get some of the functionality that you have with SQL server (entity framework, designer, etc) there are still a bunch of things that are not supported, but it's a good start
It's possible, but a number of specifics might tend to prevent a full implementation on SQL Server, particularly with respect to stored procedures.
However, if the intent is to build a scaffolding on VisStudio and finish the development using the MySQL tools, it would work okay. You'll have to learn both SQLs quite thoroughly. The sooner you do that, the less grief there will be in the conversion.
One method for doing this would be to abstract away the database itself. That be done at least a couple of ways; the first way, you could use classes to build the SQL that your application requires, and then just use that; then all that has to happen is that it has to know how to generate the right SQL for the right server. One of the drawbacks of doing it that way, though, is that if you depend on functionality that exists on only one DBMS, you'll have to emulate it in that abstraction layer.
The other method that you could use is to create two versions of your classes that talk to the RDBMS, one for MySQL and one for Microsoft's SQL Server. Use an interface and derive from it in order to do the actual implementation. Of course, you'll want to make sure that the only responsibility of the class is to interact with the database, so if you're doing this for business layer objects, you'll be implementing those sorts of things with two classes: a low-level one for the database API, and a high-level one for actually providing the API that your application is going to consume.
Perhaps not a direct answer to your question, but the dblinq project may be of use to you.
It may be worth a look just to see the MySQL implementations within the project in order to determine what the real differences between SQL Server and MySQL are going to be and how they're going to affect you. The more you can abstract out those differences behind a dependency implementation, the easier it'll be to swap out one implementation for another.
You can write your code for SQL Server and then switch to Devart LinqConnect.
For example, you can create a LINQ to SQL model using Entity Developer (in VS integration mode or in standalone mode), then change the connection to the MySQL-specific one and run Update Database from Model wizard (don't forget to select the Regenerate Storage check box).
As a result, you will obtain a MySQL database, having structure identical to the SQL Server one.
I'm creating an offline search-engine like application that's also like a dictionary, and I thought I'd use an SQL database. However, I only know database basics (a few SQL commands, how databases and relationships are supposed to work) but wouldn't like to spend a lot of time studying about them.
Is it a good idea for me to just use a visual database creation system (I was thinking MySQL Workbench), or should I learn more about databases first? And if so, how much is enough to create one of the application?
This is my first time developing software, so I am not sure how to go about it.
It is good for you
is there a windows xp utility to make a database such that its support by sql server, oracle, and other db management systems.
the database schema is very huge so i would like to know what to use to make it so its protable from sql server to oracle if future demands that change?
In short, what you seek is nearly impossible to do successfully. Every database product has enough quirks that building such database would not perform well and would be too limiting in terms of the features you were able to use. I.e, you have to play the game of lowest common denominator with respect to features that all products implement you want to support. A far better solution is to abstract the data layer into its own library accessed via interfaces so that you can swap out your data layer. ORMs, as Rafael E. Belliard suggested, makes this simpler but it can also be done manually.
I would recommend building your database using an ORM like Hibernate for Java (or NHibernate for .NET). This would allow you to seamlessly transition from one database type to the other with little to no issues. They would allow you to logically create the database schema without a specific database in mind, which you could then move from one database to the other.
I have created applications which change from SQL Server to MySQL to Oracle to MS Access to SQLite easily (clients love that flexibility).
However, you would need to know your way around programming...
I have a Databse "Product" in in sql 2008.I have another Databse "ORDER" in sql 2008.
Both exist in different servers.
Now the requirement is to Merge both databases, and test pointing the applications to this new DB.
Can anyone suggest the best way to accomplish this without losing the information?
I have 2 options.
1) Script the DB objects.(script both the DB and run this scripts inthe new DB)
2) Export DB
Which one in this is best or should i use any other methods to avoid errors.
I am new to SQL so please guide me with correct options.
Thanks
SNA
In my opinion the best way to achieve what you want is by just Exporting the database.
I think this is the best option because it's alot more safe then scripting the db's into a new one (a way to just get alot of frustration and errors).
Just try the exporting of your database first before trying to do anything with scripting (which obviously also takes alot more time). So try your fast solution first, and see if it will work.
(I see you are using sql-server 2008) Are you also using the management studio? If so, you can go into the tables in edit-mode and try to copy / paste rows into the new tables. I don't know how big your tables / DB's are, but this could also be an option.
Greetings,
Younes
As you say, two options are scripting or using the SQL server export/import wizard.
I've used both (for the same database as it happens)
A third option is to use Visual StudioTeam System 2008 Database Edition GDR.
In terms of a one time export and import then I'd recommend going with the wizard. This is very safe and also very straightforward. Particulary as you are new to SQL server, you want to take the approach that minimizes the risk.
The only downside to doing it this way is that it is perhaps a little less transparent than the other methods.
On the project where I merged databases I ended up using the scripting method but that was mainly because I had a project that was already using GDR to merge incremental database updates, so adding in a data merge script to that was a simple task - all changes needed to go through DBAs who unfortunately weren't very SQL literate (I know!) so keeping all the processes similar was a must.
I also took some of my learnings from scripting the data and applied them to setting up my reference data scripts, so the effort of scripting was not a one time cost.
Either way, the most important tip I can give is to back up the databases before doing any work on them.