 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / November 2004SQL Roadmap (longish)
Hey-hey hey Raj! I'm a Carbon person hoping to move primarily to Cocoa, and looking to do a standalone app that requires a database engine that supports lots of datatypes. It's really just an excercise to build something *substantial* in Cocoa since I no longer make a living through programming ;-( I've got a lot of database experience from long ago, but only with authoring systems like 4D; I've never crossed the database work with regular application programming. Thus I only have a passing familiarity with SQL and modern stuff. I've been boning up on MySQL, PostgreSQL, and the like. The online SQL stuff I've read is really just terminal stuff - "type these statements in to select records" and so forth. I've played with tools like Aqua Data Studio, and looked at examples of wrappers like QuickLite. At the moment I'm hoping to use one of the Mac wrappers for SQLite; perhaps QuickLite. I don't have the Tiger pre-release, so I haven't seen CoreData stuff. have to assume that the CoreData dox will make this quite easy, but they don't exist yet, and who knows how long they will take to write that stuff up! So...the question is, how to get there from here? What's the syllabus, and what direction to take? Since I don't know much beyond the Hillegass book yet, I have some ways to go in Cocoa as well. I figure I have to learn (at least) the following: * all the critical Cocoa design methods like bindings (whatever that is) and so forth * SQL database terms and techniques * using SQL from a programming language * integrating Cocoa's objects with the database i/o * using Cocoa wisely so as not to drag performance down with too much data! In the past I'd just buy 100 books and every piece of software that was available, but I have to do this on the cheap. Opines please!  SignatureNo sig, no neuroses In article <2004110309114116807%exceptionsTakeThisOutDude@earthlinknet>, > I've got a lot of database experience from long ago, but only with > authoring systems like 4D; I've never crossed the database work with [quoted text clipped - 4 lines] > played with tools like Aqua Data Studio, and looked at examples of > wrappers like QuickLite. Why? A database is just one of many ways to persist data. Unless you're doing some particular database operation, you really shouldn't need to care about much beyond NSKeyedArchiver. If Apple does the Cocoa component of CoreData right, that will be the case. If they don't, I'll be modifying STEnterprise to work with their particular take on SQLite. >> I've got a lot of database experience from long ago, but only with >> authoring systems like 4D; I've never crossed the database work with [quoted text clipped - 11 lines] > don't, I'll be modifying STEnterprise to work with their particular > take on SQLite. Do you mean that this object already supports capabilities similar to a regular relational database? I have to have relations and indexing and all that. Wouldn't that be the point of CoreData? (All I know about it is that is going to be for persistent storage and is based on SQLite.) Remember this is all new to me.... SignatureNo sig, no neuroses In article <2004110312152450073%exceptionsTakeThisOutDude@earthlinknet>, > Do you mean that this object already supports capabilities similar to a > regular relational database? I have to have relations and indexing and > all that. Wouldn't that be the point of CoreData? (All I know about it > is that is going to be for persistent storage and is based on SQLite.) > > Remember this is all new to me.... Right, which is why I question from the get-go your expressed "need" for a complex persistence mechanism. What do you actually intend to *do* that makes you think you're taking the right approach by deeply messing up your app with SQL? I say start writing your app using the technologies you have pre-Tiger. Then you can revisit what new advantages CoreData and Spotlight offer you from a data/document management standpoint. >> Do you mean that this object already supports capabilities similar to a >> regular relational database? I have to have relations and indexing and [quoted text clipped - 10 lines] > advantages CoreData and Spotlight offer you from a data/document > management standpoint. Oh, no, it's definitely a database app. Lots of complex relations, lots of tables. It's not going to be my actual first Cocoa app, but I want to kill off as much stuff as possible while I'm working through a smaller project. I can't seem to find (Amazon, O'Reily, et al) a book that says "here's how to use SQL from an appication...". Maybe I'll just wait for Tiger. Isn't it still 8 months down the road, though? SignatureNo sig, no neuroses > Oh, no, it's definitely a database app. Lots of complex relations, lots > of tables. It's not going to be my actual first Cocoa app, but I want > to kill off as much stuff as possible while I'm working through a > smaller project. I can't seem to find (Amazon, O'Reily, et al) a book > that says "here's how to use SQL from an appication...". Maybe I'll > just wait for Tiger. Isn't it still 8 months down the road, though? You can look at http://mysql-cocoa.sourceforge.net/ With this you have the results of query in NSArray, NSDictionary, NSString, etc. But you don't have the db server in your application. SignatureFrédéric Testuz >> Oh, no, it's definitely a database app. Lots of complex relations, lots >> of tables. It's not going to be my actual first Cocoa app, but I want [quoted text clipped - 6 lines] > With this you have the results of query in NSArray, NSDictionary, NSString, > etc. But you don't have the db server in your application. That's okay. The stuff on using the database from Cocoa is exactly what I need. Thanks! SignatureNo sig, no neuroses In article <2004110509044675249%exceptionsTakeThisOutDude@earthlinknet>, > Oh, no, it's definitely a database app. Lots of complex relations, lots > of tables. Nothing about that description actually screams "database". There are even application that *do* scream to use a database (e.g., Only Mortal <http://homepage.mac.com/only_mortal/>), but still work with simple archivers. > I can't seem to find (Amazon, O'Reily, et al) a book > that says "here's how to use SQL from an appication...". Because the answer is too simple for a book, and I've already given it. You treat it as an object persistence layer since, at some point, you'll need to have objects for all the Cocoa widgets to insert/update/delete it. Apple used to have EOF to do that with really complex mappings, but they screwed that pooch during the tech bubble. CoreData may eventually turn out to be (part of) a suitable replacement, but it's too early to say. Right now you haven't given any details to indicate your needs can't immediately be met by simply conforming to the NSCoding protocol. > Maybe I'll > just wait for Tiger. Isn't it still 8 months down the road, though? Select and Premier developers have had access for a while already. If you need to ship something sooner, you'll need to work more closely with 3rd party tools. If this is something that's just for you, maybe it's not worth the $500 to have Tiger pre-release APIs today. I still don't see how any of that has to do with whether or not an application requires a database for persistence. On 05/11/2004, Mikey wrote in message <2004110509044675249%exceptionsTakeThisOutDude@earthlinknet>: > I can't seem to find (Amazon, O'Reily, et al) a book > that says "here's how to use SQL from an appication...". The standard way to use SQL inside a mundane Cocoa application at the moment is to use SQLLite. This assumes that you have already ascertained that you really do need SQL and that the properties inherent in NSObjects (archiving, etc.) don't do what you want. Simon. SignatureUsing pre-release version of newsreader. Please tell me if it does weird things. > On 05/11/2004, Mikey wrote in message > <2004110509044675249%exceptionsTakeThisOutDude@earthlinknet>: [quoted text clipped - 9 lines] > > Simon. Yeah, I'm talking about multiple tables, many-to-one and many-to-many relations, the whole pile of...it. I've settled on an SQL-ish engine, and have to start learning that. The database work i did long ago was with proprietary engines (and may have predated common use of SQL for all I know). So I have to learn all that, and then integrating with Cocoa in a sensible way, etc. I'm trying to avoid getting stuck with "Database 101" or "The Console and You" chapters in whatever SQL texts I get. I'm really trying to come up with some new interface styles rather than the usual "spreadsheet-full-of-table-data-for-viewing and dialog-for-input" thing that exists everywhere (and that I worked on for years). 4D, FileMaker - yuck. It's really a pain, depending on the type of data. iTunes and iPhoto and the Finder et al aren't inspiring me....yet. In the meantime I'm going to come up with a much smaller, data-heavy, project to work on Cocoa with, and for that I'll use the NS stuff. Maybe some interface ideas will pop out. No metal windows, though. Gotta avoid that. SignatureNo sig, no neuroses >>> I can't seem to find (Amazon, O'Reily, et al) a book that says "here's >>> how to use SQL from an appication...". It'll be buried deep in the books for each SQL engine. >Yeah, I'm talking about multiple tables, many-to-one and many-to-many >relations, the whole pile of...it. Learning that much of SQL is independent of embedding it in an application. A decent general purpose SQL book can help you with that. It's a good, long-term investment to make, too! :-) Lay out your tables, relations, and indicies, and you should be able to "do" your application nearly independent of any particular SQL implementation. Embedding SQL just means you tie yourself to a particular vendor and their style of embedded SQL. For SQLite, it's just sending plain SQL commands to their handlers. For MySQL, there's a whole library of routines to use. For Informix, there was a preprocessor that translated special in-line SQL statements into C code. Great for performance, poor for portability to other SQLs. Just lay out your database carefully, play with it for awhile to be sure it's what you need, and then pick whatever flavor of SQL engine you want. That in turn will dictate how you go about using it in an application. Just my 2 cents. Good luck! > It'll be buried deep in the books for each SQL engine. > > Learning that much of SQL is independent of embedding it in an application. > A decent general purpose SQL book can help you with that. It's a good, > long-term > investment to make, too! :-) I did the old "sit on the floor for hours" at the computer bookstore this week. Lots of nice stuff, but, you're right, the stuff is buried in there. Luckily, the O'Reilly MySQL Cookbook had references for the books with C APIs, and I found them in the store....heh. What a pile! > Lay out your tables, relations, and indicies, and you should be able to > "do" your application nearly independent of any particular SQL > implementation. > Embedding SQL just means you tie yourself to a particular vendor and their > style of embedded SQL. I figured this was the right thing to do, which makes me wary of some of the existing wrappers 9without which I'd be lost). On top of this, there's CoreData, which I haven't seen yet. I'm thinking I can have some layer between the implementation, and some "homogenized" SQL. > Just lay out your database carefully, play with it for awhile to be > sure it's what you need, and then pick whatever flavor of SQL engine > you want. That in turn will dictate how you go about using it in an > application. Yes, I plan to work it out just from the command line and with the server-based MySQL. My first attempt will be a conversion from a project that was originally a 4D database, so I have to scrape out a lot of fluff. I'll work that to death (I already have about 25k records from the 4D thing), and convert my thinking to SQL. > Just my 2 cents. > Good luck! Thanks! Now that I've started getting some info, the clouds are thinning.... SignatureNo sig, no neuroses On 11/11/2004, Mikey wrote in message <2004111110500827544%exceptionsTakeThisOutDude@earthlinknet>: > Yes, I plan to work it out just from the command line and with the > server-based MySQL. Once you've got it set up I strongly recommend that you try CocoaMySQL for viewing and maintenance. Simon. SignatureUsing pre-release version of newsreader. Please tell me if it does weird things. > On 11/11/2004, Mikey wrote in message > <2004111110500827544%exceptionsTakeThisOutDude@earthlinknet>: [quoted text clipped - 6 lines] > > Simon. Yes! This is one of the first things I downloaded; it looks like a great tool. SignatureNo sig, no neuroses >> On 11/11/2004, Mikey wrote in message >> <2004111110500827544%exceptionsTakeThisOutDude@earthlinknet>: [quoted text clipped - 8 lines] > > Yes! This is one of the first things I downloaded; it looks like a great tool. I finally got started this morning, and CocoaMySQL turned out to be invaluable. What a great tool this is. I didn't do too bad thru the terminal for the first few hours (the friggin' access permssions were a drag), but then CocoaMySQL really got me going. I was unable to get mysqlimport working, but CocoaMySQL handled it perfectly. It didn't use mysqlimport, btw, but who cares. SignatureNo sig, no neuroses > Yeah, I'm talking about multiple tables, many-to-one and many-to-many > relations, the whole pile of...it. I've settled on an SQL-ish engine, [quoted text clipped - 4 lines] > "Database 101" or "The Console and You" chapters in whatever SQL texts > I get. That's not relevant for the need for a database. If you have less than 100 MByte of data and no multi-user concerns, a SQL engine is the wrong way to go. Take a look at prevayler(.org). Stephan Eggermont > > Yeah, I'm talking about multiple tables, many-to-one and many-to-many > > relations, the whole pile of...it. I've settled on an SQL-ish engine, [quoted text clipped - 8 lines] > than 100 MByte of data and no multi-user concerns, a SQL engine is > the wrong way to go. Take a look at prevayler(.org). ...and if you don't happen to be using Java? SignatureTom "Tom" Harrington Macaroni, Automated System Maintenance for Mac OS X. Version 2.0: Delocalize, Repair Permissions, lots more. See http://www.atomicbird.com/ > > That's not relevant for the need for a database. If you have less > > than 100 MByte of data and no multi-user concerns, a SQL engine is > > the wrong way to go. Take a look at prevayler(.org). > > ...and if you don't happen to be using Java? Well, looking at the provided site shows ports to other languages, but it's still the "wrong" solution. All it seems to be is what you already get in Cocoa with archivers and distributed objects. The site itself even notes that Prevayler is not a database: http://www.prevayler.org/wiki.jsp?topic=PrevaylerIsNotADatabase I suggested just using archivers, including those that bridge to SQLite, and was shot down. The size of the data really has nothing to do with how useful a relational database is, but even the OP didn't elaborate on what is being done that required any elaborate form of data persistence. Without those details, this thread is all but pointless. > > That's not relevant for the need for a database. If you have less > > than 100 MByte of data and no multi-user concerns, a SQL engine is > > the wrong way to go. Take a look at prevayler(.org). > > ...and if you don't happen to be using Java? You use the objective-c version, of course. Stephan Hi Simon, I beg to differ. These are some of the options you have: http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers Just jump to the Objective-C section. Have you looked at QuickLite at all? -- Tito In article <2004110509044675249%exceptionsTakeThisOutDude@earthlinknet>, Mikey <exceptionsTakeThisOutDude@earthlink.net> wrote: > I can't seem to find (Amazon, O'Reily, et al) a book > that says "here's how to use SQL from an appication...". Maybe I'll > just wait for Tiger. Isn't it still 8 months down the road, though? You get a copy of the database's C API and integrate that into your application. Wade |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.