Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We're all familiar with basic ORM with relational databases: an object corresponds to a row and an attribute in that object to a column, though many ORMs add a lot of bells and whistles.
I'm wondering what other alternatives there are (besides raw access to the data). Alternatives that just work with relational databases would be great, but ones that could work with multiple types of backends besides just SQL (such as flat files, RSS, NoSQL, etc.) in a uniform manner would be even better. I'm more interested in ideas rather than specific implantations and what languages/platforms they work with, but please link to anything you think is interesting.
Your basic choices are:
Just use raw SQL.
Pick an ORM that meets your needs. Most platforms have a variety of choices. - for example the .NET platform supports LINQ, nHibernate, Entity Framework, etc.
Write your own ORM and/or data access framework.
I'm working in something more or less along the lines you have said. I think that data-store related tools have grown complex with time instead of simpler and more usable.
So, instead to add complexness, this kind of things must be as simple as:
Get something that points to the data
Use it to do something with the data (query or modify)
The thing you use to interact with the data should do some kind of (transparent) adaptation to the data-store you are working with, and done.
The translation thing may sound a bit ORM-like, but I'm speaking of something more generic:
Some kind of internal implementation to communicate with whatever you are working with (something similar to a JDBC driver, but without the need to work with SQL)
Some kind of mapping to convert data to java object (more or less like in ORM)
The implementation of these concepts I've developed is for java and you can see more of it at http://www.bryghts.com
Right now, I've only developed an engine for SQL related data-sources, but it's prepared for independence of it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Using MongoDB/CouchDB or any document based DB have a great and extensive documentation with Node.js. However, SQL usage (both raw and with ORMs) with Node have significantly less documentation and community backing. Why do very few people (at least on tutorials, public projects) use Node.js with SQL or ORMs in comparison to those who uses NoSQL?
All I see for Node.js is the MEAN stack and various NoSQL set ups (bundled in things like meteor). It's very strange for me to see so little content and a very small community working on Node and SQL. Although ORMs have performance drawbacks, I also hear a lot of drawbacks of using non-relational databases (like startups failing, etc) as opposed to SQL's reliability and age, plus ORMs solve the Object-Impedence mismatch issue.
I had to use SQL on a Node project and to cope with this, I used the most popular Node ORM Sequelize to map my JavaScript code to SQL queries so that I could focus on using one language, but the documentation and community is lacking and as a result it took a lot of time for me to discover how to use it in simple ways that would take me minutes on MongoDB.
Are Node and SQL not meant to work together?
For comparison, release dates:
Oracle: 1979
Java: 1995
Node: 2009
MongoDB: 2009
Node is a new technology that is often used with other new concepts and trending architectures. There is nothing wrong in using ORM/RDMS with Node, but usually, when a big company migrates to develop new systems with Node or a startup decides to build things with Node, they are also willing to try new architectures and solutions like NoSQL, memory databases, cloud services, etc.
RDBMSs are stable, powerful, you can build things with less risks and have more experienced developers in the market, but is an old technology. As a traditional technology, its more common to be accompanied with other traditional programming languages.
Also, Node uses JavaScript that have the best JSON support, which is great for NoSQL databases and JavaScript is untyped/weakly typed language, which creates some small issues to use ORM tools.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm not going to make a big long rattle on this question about what I've tested and number crunching. I'm more interested in actual up-to-date practice performances.
I've read tons of articles already and some of them are pretty skeptical or either very pro to one library. I'm currently testing a bit with gorp, yet I have no clue how to compare the performances of such a library towards others.
I know gorp is an extra layer that tries to add ORM to the basic SQL driver/implementation, but seeing Go's extremely clear code and being it very close to the bone on everything it does. It's not like with PHP/Python/JAVA what I'm used too, where you have to navigate through endless layers of complexity to actually see what a package does in its essence.
So my question is if anyone can share (benchmarks are always welcome :) ) their experience and knowledge on this subject.
I don't think a NoSQL-type solution is an option for my projects. All my projects always strongly depend on business logic and intertwined relationships. I also wonder if Postgres will be a win over MySQL. With Django (Python) I noticed significant performance gain using Postgres, but I never found prove on that matter if it was due to the Postgres core implementation or just Django's way of using the wrapper.
Small update
After rereading the question I noticed I kind of missed the actual goal of it. I'm actually looking for the most suitable SQL solution that will least slow down Golang itself. I know the SQL runs concurrent, but also concerning heavy traffic when running it as a web service. I won't be really bothered to drop the ORM part again if that will get me major gain on performance.
If you need to use an ORM sqlx or gorp are good Go options. Personally, I am a bit old school and I would rather for a given type Foo, I would rather write a FooDB struct that implements a FooDS interface. Everything in your app just uses FooDS. (DB = database, DS = datastore)
Your FooDB implementation could be using any number of underlying technologies MongoDB, LevelDB, SQL, etc and it can change as your app changes and this change is transparent to the rest of your app (since the rest of your app uses FooDS).
I would default to using database/sql (Prepared statements, etc) and the most mature Go SQL driver is Julien Schmidt's MySQL driver: https://github.com/go-sql-driver/mysql
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I know very well about the traditional arguments about why Interface Inheritance is prefered to multiple inheritance, there has been already a post here :
Should C# have multiple inheritance?
But according to Stroustrup the real reason why Microsoft and Sun decided to get rid off multiple inheritance is that they have vested interest to do so: instead of putting features in the languages, they put in frameworks so that people then become tied to their platform instead of people having the same capability at a language standard level.
What do you think ?
Why Sun and Microsoft consider developers too immature to just make the choice themselves ?
Above is my explicit interpretation of what he said. Of course he did say that in a more politically-correct way :)
Excerpt from "A Conversation with Bjarne Stroustrup"
http://www.artima.com/intv/modern.html
People quite correctly say that you
don't need multiple inheritance,
because anything you can do with
multiple inheritance you can also do
with single inheritance. You just use
the delegation trick I mentioned.
Furthermore, you don't need any
inheritance at all, because anything
you do with single inheritance you can
also do without inheritance by
forwarding through a class. Actually,
you don't need any classes either,
because you can do it all with
pointers and data structures. But why
would you want to do that? When is it
convenient to use the language
facilities? When would you prefer a
workaround? I've seen cases where
multiple inheritance is useful, and
I've even seen cases where quite
complicated multiple inheritance is
useful. Generally, I prefer to use the
facilities offered by the language to
doing workarounds.
From "Interview of Bjarne Stroustrup by "Developpeur Reference""
http://www2.research.att.com/~bs/nantes-interview-english.html
You can always re-write an example using multiple inheritance into on the uses single inheritance only (by using forwarding functions). However, the result is often an example that is longer, reflect the design less directly, and is harder to maintain. Note that you can also rewrite every example using single inheritance to an example using no inheritance using the same technique and with the same negative impact on code clarity. A language that does not support multiple inheritance is simply less expressive than one that supports multiple inheritance and thereby forces the programmer to occasionally complicate code.
...
People talk a lot about frameworks, but history is littered with frameworks that didn't live up to their expectations. I have seen successful frameworks, but they were generally limited in scope. I'm skeptical of "universal" frameworks, and even more so when such frameworks are products of a platform vendor competing with similar frameworks from other vendors. As a user, I prefer to maintain my independence from vendors as far as possible.
I'd like to seen libraries providing cleaner and more general access to frameworks - as opposed to languages intimately tied to a single framework.
My own thought:
People do follow fashion and IT is no exception. Nobody dares to question the fundamentals until some Gurus have themselves interest to do so.
For example in the case of Java nobody dared to question EJB until Rod Johnson came along with another framework which he said was inspired by .NET pragmatism.
And now .NET is becoming itself more and more frameworklish with EF.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
With all the key value data stores out there I have started to create an abstraction layer so that a developer does not have to be tied in to a particular store. I propose to make libraries for:
Erlang
Ruby
Java
.NET
Does anyone have any tips on how I should go about designing this API?
Thanks
First off, and as a general rule for anytime you build "pluggable" abstraction layer, build it to support at least two real implementations to start. Don't build it for just one datastore and try to make it abstracted, because you'd overlook a details that won't plug into another implementation very well. By forcing it to use two seperate implementations, you'll get closer to something that is actually flexible, but you'll have to make further changes to support a third and fourth data store.
Second, don't bother, these things already exist. Microsoft has provided a ton of these for their technologies (ODBC, ADO, ADO.NET, etc), and I'm sure Ruby/Java/etc has several as well. I understand the desire to encapsulate the already existing technology, but the more data stores you need to support, the more complexity you need to build in, and the closer you'll get to ADO.NET (or similar technologies). Companies like MS have spent a ton of money and research on solving this exact problem, and that is what they came up with.
I would strongly recommend checking out Twitter's Storehaus project - this is a key-value store abstraction layer for the JVM and written in Scala, supporting (to date) Memcache, Redis, DynamoDB, MySQL, HBase, Elasticsearch and Kafka.
Storehaus's core module defines three traits:
A read-only ReadableStore with get, getAll and close
A write-only WritableStore with put, putAll and close
A read-write Store combining both
In the Ruby ecosystem, you should check out moneta, which again provides a unified interface to key/value stores. It has a lot more features than Storehaus.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
As the years go by we get more and more applications. Figuring out if one application is using a feature from another application can be hard. If we change something in application A, will something in application B break?
We have been using MediaWiki for documentation, but it's hard to keep the data up-to-date.
I think what we need is some kind of visual map of everything. And the possibility to create some sort of reference integrity? Any ideas?
I'm in the same boat and still trying to sell my peers on Enterprise Architect, a CASE tool. It's a round trip tool - code to diagrams to code is possible. It's a UML centric too - although it also supports other methods of notation that I'm unfamiliar with...
Here are some things to consider when selecting a tool for documenting designs (be they inter-system communication, or just designing the internals of a single app):
Usability of the tool. That is, how easy is it to not only create, but also maintain the data you're interested in.
Familiarity with the notation.
A. The notation, such as UML, must be one your staff understands. If you try using a UML tool with a few people understanding how to use it properly you will get a big ball of confusion as some people document things incorrectly, and someone who understands what the UML says to implement either spots the error, or goes ahead and implements the erroneously documented item. Conversely more sophisticated notations used by the adept will confound the uninitiated.
B. Documentation isn't/shouldn't be created only for the documenters exclusive use. So those who will be reading the documentation must understand what they're reading. So getting a tool with flexible output options is always a good choice.
Cost. There are far more advanced tools than Enterprise Architect. My reasoning for using this one tool is that due to lack of UML familiarity and high pressure schedules, leaves little room to educate myself or my peers beyond using basic structure diagrams. This tool easily facilitates such a use and is more stable than say StarUML. (I tried both, StarUML died on the reverse engineering of masses of code -- millions of lines) For small projects I found StarUML adequate for home use, up until I got vista installed. Being opensource, it's also free.
With all that said, you will always have to document what uses what, that means maintaining the documentation! That task is one few companies see the value in despite its obvious value to those who get to do it. . .