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
Related
I am currently working on a project which include some "little" database, however I got into the question of "should I made the relational modeling of the db and then export it into a sql query" or " should I manually create the database via sql instructions". since I've heard that creating db with frameworks (modeling) limits the db flexibility for further updates. however creating a DB on pure SQL instructions would allow me to do stuff much more easily.
Is that actually truth? or in the industry there is always a model?
The best practice when creating a database would be to model what is required using a Schema diagram first. That way you can easily change it around as required if you need to rework something and it is clear in your head what you are trying to achieve. So many times, people (myself in included) start coding things without it clear in their mind what they are trying to achieve and that makes the coding impossible. You can use software tools or pen and paper to create your diagram. Only when it makes sense in terms of the design should you start creating the database (Measure twice, cut once as the old saying goes)
In terms of creating the database, you can use code or a GUI (most products support both to my knowledge) and it is a matter of preference really.
I find writing the SQL code to be the best approach as you know exactly what is happening (GUIs can add things without your knowledge) plus you have a documented trail of what you have done in the form of an SQL script.
Not 100% sure if this answers what you asked but hopefully it helped
In HTML+CSS+JS world, http://jsfiddle.net/ is very helpful tool for asking / making example about web development. And I also saw several browser(javascript)-based programming language compilers and REPLs. But I can't find online / web-based test environment for database operations( especially for RDBMS ).
Is there any open/free database service with web-based interfaces for testing queries?
Added: This tool will be good for this situation; If I'm troubling with complex queries, then create a sample table via web interface and ask it on stackoverflow with the 'sample table URL'. Anyone can access to the URL and test their queries on web site. (Yes, queries are running on 'real' database system) And also the query results can be tracked, then we can even make 'ranking' for it :)
Try SQL Fiddle.
You can try your SQL query and execute/test it.
There are free "disposable" database servers like db4free and even MonoQL.
As far as the web-based interfaces and short URLs go, I don't think you'll have much luck.
To manage your data you have to stick to what is provided (usually phpMyAdmin or similar) and there is no short-URL to query mapping. One other caveat of such system is that (without the appropriate user permissions) one user could easily destroy all your test data -- and remember that (relational) database versioning is much more expensive than plain text versioning, so that's pretty much out of the question.
For non-RDBMS, I can think of try.mongodb.org -- but it suffers from the same problems.
Almost forgot, the Stack Exchange Data Explorer, lets you practice T-SQL queries (with permalinks).
PS: As a personal side-note, I think it's a cool idea and I would love to see something like that implemented, perhaps even mashed-up with SchemaBank or similar - that would be just awesome.
You can't really test a query without the right underlying dbms, schemas (or databases), tables, constraints, stored procedures, and permissions, which tend to be highly application specific. (That is, not readily reusable among multiple users.)
Instead, the database world has grown up into database management systems that you can freely download and install locally. Then you can build and populate your own tables, and test your queries however you like.
Most of these come with both a command line interface and some kind of graphical interface. It's not clear to me what a web-based interface would give you that doesn't already exist in one form or another.
I think that, to do what you want, would require commercial licenses for Oracle, DB2, SQL Server, and Sybase. That's a pretty high barrier to entry for a free web site.
Trouble with a web based query analyser is that you'd need to let it 'tunnel' on to your box to run the queries and for many making a development/test box open to the internet is not a possibility.
For a non web based tool you could look at LinqPad http://www.linqpad.net/ - it does Linq & Sql and other stuff too - very handy tool indeed
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 remember in my previous job, i needed to do data migration. in that case, i needed to migrate to a new system, i was to develop, so it has a different table schema. i think 1st, i should know:
in general, how is data migrated (with the same schema) to a different DB engine. eg. MySQL -> MSSQL. in my case, my destination DB was MySQL and i used MySQL Migration Toolkit
i am thinking, in an enterprise app, there may be stored procedures, triggers that also need to be imported.
if table schema is different, how will i then go abt doing this? in my prev job, what i did was import data (in my case, from Access) into my destination (MySQL) leaving table structures. then use SQL to select data and manipulate as required into final destination tables.
in my case, where i dont have documentation for the old db, and the columns was not named correctly, eg. it uses say 'field1', 'field2' etc. i needed to trace from the application code what the columns mean. any better way? or sometimes, columns contain multiple values in delimited data, is reading code the only way?
I really depends, but from your question I assume you want to hear what other people do.
So here is what I do in my current project.
I have to migrate from Oracle to Oracle but to a completely different schema.
The old system was 2-tier (old client, old database) the new system is 3-tier (new client, business logic, new database). We have more than 600 tables in the new schema.
After much pondering we scraped the idea of doing a migration from old database to new database in SQL. We decided that in our case i would be much easier to go:
old database -> old client -> business logic -> new database
In the old database much of the data is stored in strange ways and the old client
mangles it in complex ways. We have access to the source code of the old client but it is a very large system.
We wrote a migration tool that sits above the old client and the business logic.
We have some SQL before and some SQL after that but the bulk of data is migrated via
old client and business logic.
The downside is that it is slow, a complete migration taking more than 190 hours in our case but otherwise it works well.
UPDATE
As far as stored procedures and triggers are concerned:
Even as we use the same DBMS in old and new system (both Oracle) the procedures and
triggers are written from scratch for the new system.
When I've performed database migrations, I've used the application instead a general tool to migrate the database. The application connects to two databases and copies objects from one to the other. You don't have to worry about schema or permissions or whatnot since all that is handled in the application, just like what happens when you set up the application in the first place.
Of course, this may not help you if your application doesn't support this. But if you're writing an application, I strongly recommend doing it this way.
I recommend the wikipedia article for a good overview and links to the main commercial tools (and some non-commercial ones). Stored procedures (and kin, e.g. user-defined function), if abundant, are going to be the "hot spots" in the migration, requiring rare abd costly human skills -- as soon as you get away from the "declarative" mood of mainstream SQL, and into procedural code, you cannot expect automated tools to do a decent job (Turing's Theorem says that they actually can't, in a sufficiently general case;-). So, you need engineers with a good understanding of the procedural trappings of BOTH engines -- the one you're migrating from, the one you're migrating to. You can buy that -- it's one of the niches where consultants make REALLY good money!-)
If you are using MS SQL Server, you can use SSMS to script out the schema and all data in one go: SQL Server 2008: Script Data as Inserts.
If you are not using any/many non-standard SQL constructs, then you might be able to manually edit this scipt without too much effort.
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.