|
Roger Wright wrote: It's on a par with psychics using terms such as "magnetic field" and "electric force" to describe psychic phenomena
I was browsing this new age magazine while waiting to check out at the grocery store. The typical article goes like this: mention Feynman or Einstein, mention quantum physics, use authorities and science to then say, see? we have scientific proof that our ideas are correct. This one, in particular, was talking about using tuning forks on your chakras because, according to Feynman, quantum physics, and string theory, everything has a vibrational frequency. Sigh. It's one thing to just say, hey, we're trying out this funky tuning fork therapy on people. But please, don't try to bolster your ideas with logic fallacies.
[edit]And yeah, I hate it when people use that term "impedance mismatch" to describe the disconnect between the DB schema and the code representation.[/edit]
Marc
|
|
|
|
|
Marc Clifton wrote: And yeah, I hate it when people use that term "impedance mismatch" to describe the disconnect between the DB schema and the code representation
Do you have a better term? 'Disconnection between the DB schema and the code representation' seems a bit too long to me...
I don't stick to terms. Maybe because the English language is not my native one, I haven't found anything bad yet on the term 'impedance mismatch' - but this may well be because I don't get all details of it.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: Do you have a better term?
Well, "schema mismatch" or "representation mismatch" come to mind.
The hardware definition is:
mpedance matching is the electronics design practice of setting the output impedance (ZS) of a signal source equal to the input impedance (ZL) of the load to which it is ultimately connected, usually in order to maximize the power transfer and minimize reflections from the load.
Which really doesn't match, even abstractly, IMO, with what is going on between the DB schema and code.
[edit] I guess I'm experiencing an impedance mismatch in terminology, harhar [/edit]
Marc
|
|
|
|
|
Thanks for this clarification. I really didn't know that.
Marc Clifton wrote: Which really doesn't match, even abstractly, IMO, with what is going on between the DB schema and code.
I fully agree. This definition seems to totally miss the point...
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Marc Clifton wrote: using tuning forks on your chakras
Now there's a unique idea.
A musician named Stephen Halpern was using music (basic scales) to 'tune' chakras about 25 years ago. While I have to admit that the therapy had a noticable effect, he didn't resort to quoting science terms to explain it.
Anyone who uses impedance in reference to software should look up the meaning of impedance. For me, the improper usage just impedes my acceptance of the article.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Thank you. I spent the afternoon playing "planning poker" with two co-workers. The site is actually a decent gimmick for keeping a discussion on track, but doesn't really resemble any version of poker that i've ever played.
And then there are "scrums" (that don't involve full-contact sporting activities), "burn down charts" that don't involve actually burning anything, "user stories" with no narrative, and all manner of "belts" awarded to people based on their skill with statistics.
Too many programmers wishing they were doing something else...
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
I can't connect to DB2 database with EF. I think it has only MS SQL Server support like LinqtoSQL.
Some says that you can but there is no way to select other data sources like DB2 or Oracle.
|
|
|
|
|
The new drivers from Devart (formerly Core Labs) supports accessing Oracle, MySQL and PostgreSQL from the Entity Framework. There are also shipping Entity-Framework capable drivers available for SQLLite, Sybase SQL Anywhere, and a PostgreSQL driver from Npgsql.
IBM has been involved since the beginning and has demonstrated support for DB2 and Informix. Data Direct has been involved as well, and Microsoft has been working with Oracle on updating their provider to support the Entity Framework. Oracle joined Microsoft in a discussion on supporting the Entity Framework at Tech Ed, but has not made any announcements as to availablity of Entity Framework support in their provider.
We expect other vendors to upgrade their providers to support the Entity Framework in the coming months. For a list of vendors the had already committed to support for the Entity Framework as of December of last year, see http://blogs.gotdotnet.com/adonet/archive/2007/12/17/the-ado-net-entity-framework-not-just-for-sql-server.aspx.
HTH,
-Mike
|
|
|
|
|
Apparently, lots of people, seeing the amount of effort that goes in to hiding it!
SQL is not the best ever designed language but, common, it's not that bad!
Regards.
|
|
|
|
|
PedroMC wrote: SQL is not the best ever designed language but, common, it's not that bad
It is very good for interactively querying data and making changes (e.g. for DBAs and business analysts)
As a mean of handling data from applications it is horrible: typeless and prone to security flaws. Most application programmers construct SQL queries on the fly:
query = "SELECT * FROM Sometable WHERE SomeField=" + myEditControl.Text
This is pure evil
|
|
|
|
|
Nemanja Trifunovic wrote: As a mean of handling data from applications it is horrible: typeless and prone to security flaws. Most application programmers construct SQL queries on the fly:
Because most don't know SQL well.
Nemanja Trifunovic wrote: query = "SELECT * FROM Sometable WHERE SomeField=" + myEditControl.Text
In all sincerity if you think that's horrible, then in pseudocode what would you do that's so superior to go about telling a DB you want to pull values from a storage mechanism where the condition for which rested in myEditControl.Text?
I'm not saying you, but in my experience the people that knock SQL the most are the ones that know it the least. It offers a lot of nice short cuts in it as well that can shorten the amount of time you would have to query compared to writing code. Sure it has its ups and downs, but so does anything (expect me of course ).
|
|
|
|
|
Jeremy Falcon wrote: In all sincerity if you think that's horrible, then in pseudocode what would you do that's so superior to go about telling a DB you want to pull values from a storage mechanism where the condition for which rested in myEditControl.Text?
Something like:
result = DataStorage.GetSomething(myEditControl.Text)
But even with SQL, there are parameterized SQL queries (even in MySQL these days, since version 5.0 or something ) which would at least prevent SQL injections.
|
|
|
|
|
Nemanja Trifunovic wrote: result = DataStorage.GetSomething(myEditControl.Text)
But you can do that with a wrapper already if you prefer objects over a query string.
Remember, SQL specifies syntax that's meant to be standardized, much like how XML, HTML, etc. does, so you don't get everyone and their mother specifying their own thing underneath the hood. It's not supposed to interact with objects in your app intrinsically as it was never created for that means, and you would throw portability out the window that way as then data access would be solely dependent on the environment accessing the data rather than database.
|
|
|
|
|
Jeremy Falcon wrote: But you can do that with a wrapper already if you prefer objects over a query string.
If my wrapper internally does the same thing (appends a user-supplied string to a query) then there is no point.
SQL is inherently bad, for the similar reasons printf(...) is bad: it requires an interpreter that blindly executes strings that often contain parts supplied by users. I attended a couple of security seminars lately, and examples of exploiting this fact were abundant.
|
|
|
|
|
The same argument could be said about a programming language. Especially the ones that allow you to dynamically execute code.
What I'm getting at is SQL does more good than harm by providing an open means rather than closing it off. Abusing it is bad, then again so is anything.
|
|
|
|
|
Nemanja Trifunovic wrote: As a mean of handling data from applications it is horrible: typeless and prone to security flaws. Most application programmers construct SQL queries on the fly:
Btw, SQL isn't typeless. It's loosely typed, but that's not the fault of SQL, that's the fault of MS and SQL Server as that's one of the most forgiving RDBMSes out there. Some like that, some don't. But even still, it's not hard to enforcing typing in the application before it's sent to the DB.
|
|
|
|
|
Jeremy Falcon wrote: that's the fault of MS and SQL Server as that's one of the most forgiving RDBMSes out there.
|
|
|
|
|
What I'm trying to say is SQL Server is so forgiving it starts to loose the value of its intrinsic data types because you can mix and match so easily in it whereas you can't in other RDBMSes.
|
|
|
|
|
Jeremy Falcon wrote: What I'm trying to say is SQL Server is so forgiving it starts to loose the value of its intrinsic data types because you can mix and match so easily in it whereas you can't in other RDBMSes.
I was not talking about that, but would like to see some evidence anyway
|
|
|
|
|
How about how SQL Server will implicitly convert between int and string for example?
SELECT 1 WHERE 1='1'
Though I don't know if that's unique to SQL Server, it could be the standard behaviour, either way I would prefer an Exception.
What's really crazy is that (if I recall correctly) it converts the string to int rather than the other way around. ![WTF | :WTF:](https://www.codeproject.com/script/Forums/Images/smiley_WTF.gif)
|
|
|
|
|
PIEBALDconsult wrote: Though I don't know if that's unique to SQL Server, it could be the standard behaviour, either way I would prefer an Exception.
That's valid in MySQL too, but MySQL offers a few tidbits to overcome it. It's not perfect, but it's something. For instance...
SELECT * FROM news WHERE 1 = '1.0';
...would match, but...
SELECT * FROM news WHERE BINARY 1 = BINARY '1.0';
...would not match.
|
|
|
|
|
Jeremy Falcon wrote: SELECT * FROM news WHERE BINARY 1 = BINARY '1.0';
|
|
|
|
|
Well my point was, SQL Server is even worse AFAIK. But, type safety aside, SQL in general still does way more good than harm. Imagine data access without it. Everyone would have their own binary implementation of access and the lock down to RDBMS and how it be used would be way worse than it is already.
|
|
|
|
|
Jeremy Falcon wrote: But, type safety aside, SQL in general still does way more good than harm.
In general? Yes - for interactive tasks that are mostly done by a dba or a business analyst.
For getting the data by applications that programatically construct SQL queries by appending strings? No!
I rest my case
|
|
|
|
|
Nemanja Trifunovic wrote: For getting the data by applications that programatically construct SQL queries by appending strings? No!
Sorry, but I disagree. Even in this instance you'd be worse off with no open standard underneath the hood. In fact SQL is probably the main reason RDBMSes are even so popular these days, because you know how to use them.
Now, imagine you writing a program that uses SQL Server with some obscure MS technology to use in your code, but wait, the customer wants to also access the data from the web in a PHP application. You're screwed, unless someone took the time to write a library, and even then there's no guarantee their lib would be compatible with your code. With SQL, the connectors is the only thing that faces this limitation.
And not to mention, there would be no standard way to represent the data in the first place without SQL. Which means everyone would have to learn your app's implementation and possibly whatever language you used with it, just to make sense of your DB.
I rest my case, we're better off with SQL than without.
|
|
|
|