Re: To MySQL or Not SQL
What about the differences between MySQL and MSSQL. The proponents of MSSQL
are adamant that it is far better. Is it really? Of course, it's not
x-platform, which is a mark against it in my books... Jim
on 4/25/05 3:58 PM, Bill wrote:
Yes I agree that SQL is the way to go. I can't wait until the MySQL to
SQLite utility is released so that I can try SQLite. I think it will be
faster at connecting.
On 4/25/05 2:17 PM, Dan Shafer [EMAIL PROTECTED] wrote:
Anyone else thinking along these lines?
|||
)_) )_) )_)
)___))___))___)\
)))_)\\
_|||\\\__
---\ /- http://www.bluewatermaritime.com
^ ^
^^^^^
^^^
24 hour cell: (787) 378-6190
fax: (787) 809-8426
Blue Water Maritime
P.O. Box 91
Puerto Real, PR 00740
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
--
OYF is... Highly resourceful people working together.
http://www.OwnYourFuture-net.com
Own Your Future Consulting Services Limited,
1959 Upper Water Street, Suite 407, Halifax, Nova Scotia. B3J 3N2
Phone: 902-823-2339. Fax: 902-823-2139
What¹s New...
* Have you ever hired an employee who didn¹t work out?
* Did you do that on purpose?
Probably not...
If you want to greatly improve your hiring process,
check out our new hiring process... www.HiringSmart.ca/ns
http://www.hiringsmart.ca/ns
and...
www.KeepingTheBest.ca/ns http://www.keepingthebest.ca/ns
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's one of the few databases I'd consider inferior to MySql, not because it lacks cross-platform compatibility, but because it is a Microsoft product ;-) Realistically, any of the major database servers will have advantages and disadvantages compared to the others. I personally like PostgreSQL: it is free for both noncommercial *and* commercial use (unlike MySql, which is only free for non-commercial use), it is reasonably fast and quite powerful, fully ACID-compliant, supports stored procedures, views, and so forth, has a sizable user community, etc. And it runs just fine on my OS X box, along with Windows, Linux, and a variety of other platforms. On Apr 26, 2005, at 8:49 AM, Jim Carwardine wrote: What about the differences between MySQL and MSSQL. The proponents of MSSQL are adamant that it is far better. Is it really? Of course, it's not x-platform, which is a mark against it in my books... Jim on 4/25/05 3:58 PM, Bill wrote: Yes I agree that SQL is the way to go. I can't wait until the MySQL to SQLite utility is released so that I can try SQLite. I think it will be faster at connecting. On 4/25/05 2:17 PM, Dan Shafer [EMAIL PROTECTED] wrote: Anyone else thinking along these lines? ||| )_) )_) )_) )___))___))___)\ )))_)\\ _|||\\\__ ---\ /- http://www.bluewatermaritime.com ^ ^ ^^^^^ ^^^ 24 hour cell: (787) 378-6190 fax: (787) 809-8426 Blue Water Maritime P.O. Box 91 Puerto Real, PR 00740 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution -- OYF is... Highly resourceful people working together. http://www.OwnYourFuture-net.com Own Your Future Consulting Services Limited, 1959 Upper Water Street, Suite 407, Halifax, Nova Scotia. B3J 3N2 Phone: 902-823-2339. Fax: 902-823-2139 Whats New... * Have you ever hired an employee who didnt work out? * Did you do that on purpose? Probably not... If you want to greatly improve your hiring process, check out our new hiring process... www.HiringSmart.ca/ns http://www.hiringsmart.ca/ns and... www.KeepingTheBest.ca/ns http://www.keepingthebest.ca/ns ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution - --- Frank D. Engel, Jr. [EMAIL PROTECTED] $ ln -s /usr/share/kjvbible /usr/manual $ true | cat /usr/manual | grep John 3:16 John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. $ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCbkJa7aqtWrR9cZoRAsoQAJ0aMN6w4NN3gIgLL0JSNe6qY67FzACfab9U WgSg71YvUbOWBSxrn/KLB1k= =mwRm -END PGP SIGNATURE- ___ $0 Web Hosting with up to 200MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
I'd get a copy of the SQL Pocket Guide, via Oreilly press. They might even list out the differences at the www.oreilly.com site. However, to answer the question, I feel MySQL is very adequate, even robust, for most of the Rev applications I see discussed here. And with the aforementioned libraries, fairly simple, almost fun to implement. Having not one but two competing local SQL server products, Rev rocks again. Not having to create my own data storage and retrieval scheme is wonderful and I can move on to 'business logic' and interface and getting the app out the door. At 9:49 AM -0300 4/26/05, Jim Carwardine wrote: What about the differences between MySQL and MSSQL. The proponents of MSSQL are adamant that it is far better. Is it really? Of course, it's not x-platform, which is a mark against it in my books... Jim ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
Pierre. I think you meant to refer to Trevor's libDB libraries here. Just in case someone gets confused. I really agree with you about SQL being the perfect Rev sister ship, though, and I like the analogy. One thing I've been thinking about a lot lately in conjunction with a set of apps I'm doing for my main client, is whether or not to use altSQlite out the gate for all data storage, skipping over cards and custom properties altogether (I'm talking about storage of record-type data here, not things for which cards and props are decidedly correct). One big advantage of that approach is that if the client's needs change and suddenly he wants the data on a networked server with a robust database, I don't have to change my code except for the connect stuff (typically one line) for it to just work. Since I seem to attract clients whose needs always change (I think that's why we call them clients), this has a lot of attraction for me. And now that altSQLite has overcome all the objections I had to Valentina (primarily the costs), this approach makes more and more sense to me. Anyone else thinking along these lines? On Apr 24, 2005, at 12:00 PM, Pierre Sahores wrote: SQL is, probably, in about direct to disk datas storage and management, the perfect Rev sister-ship and, with the help of Chipp's libraries, a piece of cake to set-up. Leaen once how to drive SQL back-ends from within Rev and you will than use this winning combination all the time :-) ~~ Dan Shafer, Co-Chair RevConWest '05 June 17-18, 2005, Monterey, California http://www.altuit.com/webs/altuit/RevConWest ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
Yes I agree that SQL is the way to go. I can't wait until the MySQL to
SQLite utility is released so that I can try SQLite. I think it will be
faster at connecting.
On 4/25/05 2:17 PM, Dan Shafer [EMAIL PROTECTED] wrote:
Anyone else thinking along these lines?
|||
)_) )_) )_)
)___))___))___)\
)))_)\\
_|||\\\__
---\ /- http://www.bluewatermaritime.com
^ ^
^^^^^
^^^
24 hour cell: (787) 378-6190
fax: (787) 809-8426
Blue Water Maritime
P.O. Box 91
Puerto Real, PR 00740
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
Hello Dan, Trevor and All, Pierre. I think you meant to refer to Trevor's libDB libraries here. Just in case someone gets confused. All my apologies, Trevor. As you are remembering, Dan, i just wants to speak from your libDatabase client-server dedicated usefull framework, Trevor and from the Chipp's altSQLlite one in about the Rev's embbedable SQLlite solutions... I really agree with you about SQL being the perfect Rev sister ship, though, and I like the analogy. One thing I've been thinking about a lot lately in conjunction with a set of apps I'm doing for my main client, is whether or not to use altSQlite out the gate for all data storage, skipping over cards and custom properties altogether (I'm talking about storage of record-type data here, not things for which cards and props are decidedly correct). One big advantage of that approach is that if the client's needs change and suddenly he wants the data on a networked server with a robust database, I don't have to change my code except for the connect stuff (typically one line) for it to just work. Exactly the same motivations there, Dan... When Rev let us code our apps teen times faster and securly than in going down with UML+Java miseries (core-coding or low-level frameworks), when ACID-SQL back-ends let us learn how to let powerfull transactions managers handle the security of our datas, we are going head with more and more reliable and powerfull ways to design and build great xtalk's solutions... Is'n it just : cool ? Best, :-) Pierre Since I seem to attract clients whose needs always change (I think that's why we call them clients), this has a lot of attraction for me. And now that altSQLite has overcome all the objections I had to Valentina (primarily the costs), this approach makes more and more sense to me. Anyone else thinking along these lines? On Apr 24, 2005, at 12:00 PM, Pierre Sahores wrote: SQL is, probably, in about direct to disk datas storage and management, the perfect Rev sister-ship and, with the help of Chipp's libraries, a piece of cake to set-up. Leaen once how to drive SQL back-ends from within Rev and you will than use this winning combination all the time :-) ~~ Dan Shafer, Co-Chair RevConWest '05 June 17-18, 2005, Monterey, California http://www.altuit.com/webs/altuit/RevConWest ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
On 4/25/05, Dan Shafer [EMAIL PROTECTED] wrote: Pierre. I think you meant to refer to Trevor's libDB libraries here. Just in case someone gets confused. I really agree with you about SQL being the perfect Rev sister ship, though, and I like the analogy. One thing I've been thinking about a lot lately in conjunction with a set of apps I'm doing for my main client, is whether or not to use altSQlite out the gate for all data storage, skipping over cards and custom properties altogether (I'm talking about storage of record-type data here, not things for which cards and props are decidedly correct). Anyone else thinking along these lines? I absolutely agree. Personally, next to finding Rev in the first place (yeah!), Chipp's altSQlite plugin has got to be the most exciting news I've run across in quite some time. ...I've already shot my personal software budget for this month or I'd have already licensed a copy. That's okay, though next month's budget is just around the corner. :) Once the ability to use binary data is firmly in place, I see the Rev/SQlite/altSQlite combination as an almost perfect solution... ..well, that is unless Kevin and crew decide to add a native SQL database feature directly to Rev. :) -Doc- ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
To MySQL or Not SQL
I've been up and down with this 'to SQL or not SQL' thing for a while, fearing long monotonous nights debugging arcane commands and crashing, etc. which has been my experience with client server databases used with x-talks in years past. Remember Butler? Holy smoke, what a crashfest. Not helped by system 7's ODBC implementation. I've painfully worked with GoLive 6's amazing but buggy Dynamic feature, which allows you to create webpages that suck data from MySQL and others. It writes php or asp snippets to the web page as well as install a few subroutines on your site. Brilliantly executed, to a point, except it looked like they just ran out of money and stopped beta testing and debugging. Out it went, and with only one bug fix version (the first version wouldn't work at all) that was it, in typical Adobe fashion. There are no more bugs in this product. So I had to tough it out with the unfamiliar PHP code calling SQL from html. Pretty crazy. But one thing in all my struggles was constant: my MySQL server hosted at Dreamhost. I gotta tell ya, if you guys don't have an ISP that includes mySQL, python,perl,mysql, quicktime streaming on a Linux server... move!! This stuff works, and one of the benefits of my particular webhost is that MySQL is part of the deal. They maintain it, and you secure it, put data in, and use it. For $10/month! Why bother running one's own server for most projects if installation is painful? But, getting to the point, I recently started a project that included a client-server function and I felt that this might take a while to get running. I actually tried to make a 'mock-database' in globals thinking it might allow me to get on to the other parts of building and come back to it; you know, hook it up later. Well I was debugging pretty much what would start to look like SQL calls anyway, so I just scrapped it and was determined to do it the 'right' way. I got Sarah's fine SQL stack, which demonstrates some of the built-in SQL functionality of Rev, with a very nice layout and a simple dislplay of data that I hadn't seen before -- thanks for the idea..and it inspired me to just dive in. Still I needed a bit more functionality and ease...too many things to open and close, cleanup etc.. THEN.. after a tiny bit of searching I found Trevor Devore's libDB... finally, a simple, logical way to deal with database calls. And it works, fast and clean. And all based on Rev arrays. Yesterday, I reached a milestone in my project, I got a moderately complicated multi-call SQL report working...and it took about 2 weeks after I decided to go for the 'real deal'. So I'd say, if your project can use client-server functionality now or in the future, do it! Use Chipps altMYSQL lite if it's imbedded. It just works and saves time for other things, like the interface! SQL itself is pretty easy as a language. It's verbose, self describing and consists of 40 or so commands that all make sense. Sometimes it's almost like Transcript! You usually only need to know a few commands to get a listing or a single record. It's a little more involved to insert and create records, but not much with Trevor's lib. And if the data doesn't need to be entered much, one can always manage the data input side with a SQL client such as CocoaMySQL and many others. I save various SQL calls in custom properties to avoid a lot of the quoting problems, and Trevor's lib also cleans up the entered SQL calls. Speaking of verbose, I'll stop. Sorry for the long post. stephen quinn barncard (sqb) Hi Kurt, I know that there are probably those for whom working with SQL is a piece of cake; in their eyes I'm probably making things much more difficult for myself that they need be A project I was working on started down the SQL road and hit a BIG bump with the first book on actually setting up and administering an SQL network on Mac OS X. Do you like Unix command line syntax, aka Apple's Terminal application? Would you like to walk users through it over the phone as part of your support effort? Do you want to predefine every data field to the database...and assign ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To MySQL or Not SQL
So I'd say, if your project can use client-server functionality now or in the future, do it! Use Chipps altMYSQL lite if it's imbedded. It just works and saves time for other things, like the interface! SQL itself is pretty easy as a language. It's verbose, self describing and consists of 40 or so commands that all make sense. Sometimes it's almost like Transcript! You usually only need to know a few commands to get a listing or a single record. It's a little more involved to insert and create records, but not much with Trevor's lib. And if the data doesn't need to be entered much, one can always manage the data input side with a SQL client such as CocoaMySQL and many others. I save various SQL calls in custom properties to avoid a lot of the quoting problems, and Trevor's lib also cleans up the entered SQL calls. Speaking of verbose, I'll stop. Sorry for the long post. stephen quinn barncard (sqb) SQL is, probably, in about direct to disk datas storage and management, the perfect Rev sister-ship and, with the help of Chipp's libraries, a piece of cake to set-up. Leaen once how to drive SQL back-ends from within Rev and you will than use this winning combination all the time :-) -- Bien cordialement, Pierre Sahores 100, rue de Paris F - 77140 Nemours [EMAIL PROTECTED] [EMAIL PROTECTED] GSM: +33 6 03 95 77 70 Pro: +33 1 64 45 05 33 Fax: +33 1 64 45 05 33 http://www.sahores-conseil.com/ WEB/VoD/ACID-DB services over IP Mutualiser les deltas de productivité ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
