<div dir="ltr"><div><div><div>Thanks DJ. I had to read the wiki article on what am ORM was!<br><br></div>This course only has two chapters on databases, so I'm guessing we dive deeper in another course!<br><br></div>Thanks again!<br></div>Dave<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 4:36 PM, DJ-Pfulio <span dir="ltr"><<a href="mailto:djpfulio@jdpfu.com" target="_blank">djpfulio@jdpfu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ORMs are double edged.<br>
<br>
Some are buggy and create lots of opportunities for SQL-injection attacks.<br>
<br>
Some are slow and suck RAM ... like Java, Outlook, iTunes.<br>
<br>
Some will be faster to code, create better (faster/safer) SQL than an<br>
intermediate developer, only call the DBMS when results are actually needed,<br>
and protect against all the currently known attacks ... I'm talking about DBIx,<br>
of course. The ORM that all other languages wish they had. ;)<br>
<br>
Oh - and more ORMs abstract the DBMS away - swap in whatever back-end DB you<br>
like - mysql, postgres, sqlite, mariadb ... are usually each supported with<br>
others often supported like Oracle, DB2, Informix, etc. Some ORMs might support<br>
noSQL too, but using a specialized class is probably best.<br>
<br>
I haven't written any direct SQL in webapps in about 7 yrs. It just hasn't been<br>
worth my time. If there are fewer than 20K concurrent users, I wouldn't bother<br>
writing SQL until specific profiling showed it was needed.<br>
<br>
In the 1990s, my company did "migrations" for our DBs in a way similar to<br>
Rails::Migrate ... Clearly, I like that method and wish more ORMs did it that way.<br>
<br>
For internal corporate webapps, I'd always start with an ORM regardless of<br>
language - perl, python, ruby. These are each wonderful languages and folks<br>
should understand how great it is to have choices like these today.<br>
<br>
Perl + DBIx + Dancer + CPAN is an awesome toolkit for whipping out a webapp or<br>
creating an enterprise web application developed for years.<br>
<br>
Ruby + Rails/Sinatra + ActiveRecord (or one of 10 other Ruby ORMs) ... ruby-gems<br>
is only slightly less so. Gems and ActiveRecord are beasts, but ruby is a<br>
gorgeous language. Maintaining Gems takes too much RAM. I've had to add a GB of<br>
RAM to VMs to patch Gems, otherwise, the updates would never complete. Then take<br>
the RAM away to keep monthly costs reasonable.<br>
<br>
No experience with python - my personal issue with languages that care about<br>
whitespace. Wish python were my first language instead of FORTRAN 66, so I<br>
wouldn't have the issue.<br>
<br>
Of course, this is just 1 person's opinion. Certainly, direct SQL written by an<br>
expert can be great too, but getting to that level of competence is just not<br>
necessary most of the time.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 03/13/2015 03:00 PM, Charles Shapiro wrote:<br>
> Heh. Hadda look that one up. Could work great, depending on resources and<br>
> purpose.<br>
><br>
> -- CHS<br>
><br>
><br>
> On Fri, Mar 13, 2015 at 2:51 PM, DJ-Pfulio <<a href="mailto:DJPfulio@jdpfu.com">DJPfulio@jdpfu.com</a>> wrote:<br>
><br>
>> Or just use an ORM.<br>
>><br>
>> On 03/13/2015 02:36 PM, Charles Shapiro wrote:<br>
>>> Hmm. I'm not that familiar with MySQL, but in PostgreSQL the way to<br>
>> determine<br>
>>> what you want is<br>
>>><br>
>>> select<br>
>>> <a href="http://animal.id" target="_blank">animal.id</a> <<a href="http://animal.id" target="_blank">http://animal.id</a>><br>
>>> from<br>
>>> animal<br>
>>> left join<br>
>>> food<br>
>>> on<br>
>>> <a href="http://animal.id" target="_blank">animal.id</a> <<a href="http://animal.id" target="_blank">http://animal.id</a>> = food.animalid<br>
>>> where<br>
>>> <a href="http://food.id" target="_blank">food.id</a> <<a href="http://food.id" target="_blank">http://food.id</a>> is null<br>
>>> ;<br>
>>><br>
>>><br>
>>> Writing SQL queries takes some practice. One handy tip I've found is to<br>
>> write<br>
>>> the "from..." part first, then go back and fill in what columns you wish<br>
>> to select.<br>
>>><br>
>>> Doing anything based on the numeric value of the "id" field is a Bad<br>
>> Idea. In<br>
>>> most relational databases, that field just increments when you add a<br>
>> record to<br>
>>> your table. It never decrements when you delete records. That means<br>
>> that the<br>
>>> ID value itself is useless in determining what is or is not in a table.<br>
>> It's<br>
>>> only useful when it's in another table -- hence the name, "Relational".<br>
>>><br>
>>><br>
>>> Your current table setup also breaks down if you add -- say -- a goat<br>
>> which<br>
>>> wants to eat the same things as the giraffe. You're more likely to have<br>
>> several<br>
>>> animals linked to the same foods than several foods linked to the same<br>
>> animal.<br>
>>> Don't you really want a "FoodFk" in the "animal" table? Then you could<br>
>> have<br>
>>> lots of animals which eat the same thing. Of course, I reckon in<br>
>> reality you'd<br>
>>> need a jump table to link foods and animals:<br>
>>><br>
>>> food_animal { integer animalid references animal(id), integer foodid<br>
>> references<br>
>>> food(id) }<br>
>>><br>
>>> Then you could have lots of different foods and lots of different<br>
>> animals all<br>
>>> linked together.<br>
>>><br>
>>><br>
>>> -- CHS<br>
>>><br>
>>><br>
>>> On Fri, Mar 13, 2015 at 1:52 PM, David S Jackson <<a href="mailto:deepbsd.ale@gmail.com">deepbsd.ale@gmail.com</a><br>
>>> <mailto:<a href="mailto:deepbsd.ale@gmail.com">deepbsd.ale@gmail.com</a>>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I'm a MySQL newbie. I'm just starting to use Python to talk to MySQL<br>
>>> databases, but first I need to understand the MySQL query language!<br>
>>><br>
>>><br>
>>> So, I have two tables: (zoo) animal and food.<br>
>>><br>
>>> animal has the columns ID, NAME, FAMILY, WEIGHT<br>
>>><br>
>>> food has ID, ANIMALID, FEED<br>
>>><br>
>>><br>
>>> So if I go: select id, name, family, feed from animal JOIN food ON<br>
>> <a href="http://animal.id" target="_blank">animal.id</a><br>
>>> <<a href="http://animal.id" target="_blank">http://animal.id</a>>=food.animalid;<br>
>>><br>
>>><br>
>>> I get something like:<br>
>>><br>
>>> ID NAME FAMILY FEED<br>
>>> 1 Seymore Snake mice, leaves<br>
>>> 2 Gerard Giraffe leaves, grass<br>
>>> ...<br>
>>> etc<br>
>>><br>
>>> So, if I have a situation where I want to see whether an animal has<br>
>> been<br>
>>> added the animal table but may have not been added to the food<br>
>> table, how<br>
>>> would I compose that query?<br>
>>><br>
>>> That is, the animal could have been added to the animal table and<br>
>> could get<br>
>>> an id, say 10, but the food table could have 20 foods already<br>
>> entered and<br>
>>> the animal-id would be used several times.<br>
>>><br>
>>> I was thinking, is there a way I can ask, "does the highest<br>
>> <a href="http://animal.id" target="_blank">animal.id</a><br>
>>> <<a href="http://animal.id" target="_blank">http://animal.id</a>> number equal the highest food.animalid number"?<br>
>> If not,<br>
>>> what animal is not getting fed?<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br></div>