Perhaps what you mean is you hate dealing with converting the results to the data types you will use in your application?

Perhaps what you mean is you hate the administrative overhead of creating separate files and dealing with deployment when creating stored procedures?

Perhaps what you mean is you hate properly inserting your native data types into a written SQL query in a secure way?

Or do you actually hate writing SQL? To me, that's the best part of interacting with databases.

Perhaps what you mean is you hate the escape characters used to switch between html and sql.

Perhaps what you mean is you hate the MVC separation.

I do not agree with swix that drag and drop is that solution. If there is one thing that has burned me too many times it is visual programming. Visual programming, to me, converts somatic gestures into black-box code. I love casting magic spells, but the lack of tools make them hard to fix: You must start from scratch for a small change.

I believe the solution is textual: Where different text means different things, and text can be edited to correct your mistakes. This means SQL will stay.

On another subject, I can see how Model/View separation is causing great pain. Separating a simple view into 2+ files makes a distinction without a measurable benefit. How often has your model changed without touching the view? And when it did, would having it all in one file make that change harder?

From my little experience, the majority cases leave Models and Views in a 1-1 correspondence. I agree with swix that current languages make those cases needlessly difficult.

The expressiveness of SQL and performance of a mature DBMS beats the pants off of the GAE Datastore at the moment. Obviously scalability is the major benefit of App Engine, but I'm not so sure the trade-offs are worth it.

I would like to automate it more that's all. I get that SQL is required for a lot of reasons a lot of times, but for what I do currently webapps/sites/etc probably 80% could be done with some sort of tool if it existed, it's not very complex queries, but yet someone have to create them and that's time and thats boring (to me).

I don't find it interesting at all, I do like to develop stuff, websites, apps but more oriented at the visual stuff, the data to me is just.. should just be accessible there ready to play with. I guess I see writing query code as going to the toilet and taking a dump, it's not really "funny" and yet you have to do it, only that maybe the query part could be improved upon with some tooling to reduce time etc.

With Active Record you rarely if ever need to write SQL any more.

http://guides.rubyonrails.org/association_basics.html

http://guides.rubyonrails.org/active_record_querying.html

I think SQL is slowly going the way of assembly language over time - still useful to write by hand in special cases but most of the time you want to write in something higher level and have it generated automatically.

And since SQL is a fourth generation declarative language, I really don't see how it could go the same way as assembly by being replaced with imperative programming. It's already more expressive and succint, and have stronger abstractions from implementation details, than imperative programming languages.

Hibernate for Java, SQLAlchemy for Python or Class::DBI for Perl (never used that last one) would be good examples for ORMs that blend well with the language they're written for.

Performance may vary across different ORM modules; the best-of-breed ones are certainly as fast as if you'd create the SQL yourself.

http://search.cpan.org/~frew/DBIx-Class-0.08123/lib/DBIx/Cla...

If you just want to persist your application objects, then KiokuDB is even better:

http://www.iinteractive.com/kiokudb/

How is Active Record with regards to performance under load?

  clients = Client.all(:limit => 10)
  clients.each do |client|
      puts client.address.postcode
  end

  clients = Client.includes(:address).limit(10)
  clients.each do |client|
      puts client.address.postcode
  end

In addition, ActiveRecord also supports joins instead of using includes. Includes is almost always fine, unless the initial result set is large (100+ rows).

   @foo = Foo.create
   @bars = Bar.find_all_by_some_attribute(:a)
   @foo.bars = @bars #--> slow!

Any language with similar power will be just as complex.

If you just have a limited use case that you want optimized, that's what most ORMs try to do.

The problem with ORMs is that relational databases are complicated, and you often do wind up having to do manual SQL writing anyway if you want well-performing queries in edge cases. But for simple cases where you have a person table and need to make Person objects in your app... it works.

In fact, Rails used this as one of its big selling points, combined with convention-over-configuration. If you stuck to the naming patterns Rails preferred, it really would Just Work without you having to tell it anything beyond the names of your classes.

<sarcasm>Gah! You know what I hate about building software? The programming. All those data structures are no fun! Lists and arrays and vectors and hash tables and trees, red-black trees, binary trees, b-trees, tries. Why can't we have a programming language that automagically stores all our information in simple variables and just gives me the answer I want?</sarcasm>

Couple things:

1. Most of the times, when you're building a webapp, your queries depend upon user input. How would you model that in your GUI? Once you start having to do significant processing on your input to figure out what to query, the visual model falls down pretty hard.

2. I suspect that if you actually used this interface in day-to-day work, you wouldn't like it so much. There's a reason why many hardcore hackers still use the command line: once you've burned the language syntax into your brain, you can get things done much quicker than with a GUI. If you do like it, I'd encourage you to try MS Access.

http://rubyonrails.org

http://code.google.com/p/redis/

http://github.com/nateware/redis-objects

I can't say I never write queries, but on the few Grails projects I've worked on over the past 18 months or so, I've probably needed to write fewer than 15 queries total.

Any object store could be the solution for his problem. Depending on the requirements, this could be as simple as keeping everything his program needs to store in memory.

Apparently, there are some great complexities in the software engineering process which can't be visualized or simplified enough to be aided by a tool.

SQL or the programming language you have is textual dsl's, abstracting you from the details / complexities and powerful enough that you can access all the underlying functionality. ORM's, ActiveRecord pattern etc. are all another abstraction but they're not as powerful as bare SQL. As long as you don't hit their wall, you'll be OK. But keep in mind that each layer makes some functionality inaccessible.

I once wrote a visual designer for Castle ActiveRecord & NHibernate, called ActiveWriter. It was great for the begginer on that technologies. Once you need more, the tool lacks the functionality since it gets harder and harder to implement all the details of a textual DSL in a graphical DSL. Today, I prefer Fluent NHibernate for my mappings since it's more complete on the mapping front. It seems more work but it deals with the complexity better than my own graphical tool.

http://www.grails.org/GORM

I don't write create scripts, or data management stuff, or SQL of any kind.

def smithUsers = User.findAllByLastname("smith")

It's not drag/drop/gui, but it's a lot less mental friction for me when writing code.

Things that I think are a better option are:

1. Object Oriented Databases (OODB) A database that behaves like your objects. I like Gemston(Ruby & smalltalk) and db4o (java & .Net)

2. Graph databases: http://neo4j.org/ Neo4j is a graph database. It is an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables. A graph (mathematical lingo for a network) is a flexible data structure that allows a more agile and rapid style of development.

Try this alternative databases... I think they are close to the answer.

PS: ORMapping is not a solution... it always ends up being messy: "Object-Relational Mapping is the Vietnam of Computer Science" http://www.codinghorror.com/blog/2006/06/object-relational-m...

Of course if you are just building throw-away prototype or single usage app, you don't have to use RDBMS. Use object serialization, persistent hashtable, or OODBMS. Those tend to mesh well with the language you are using.

I'm positive there is some framework that makes touching a DB barely needed, but I don't personal know it. I'm going to upvote your thread and hope somebody comes along and tells you what it is.

Write it yourself? If you did it well, maybe it would help other people understand your point.

I assure you, this is an even harder problem than it sounds.

An SQL statement tells you in almost-English exactly what to expect

The SQL standard allows me to understand what's going on in an MSSQL query when I've never used MSSQL before.

Conclusion: even though you say writing queries is easy for you, it probably isn't. Once you familiarize yourself better with SQL, you will appreciate it.