LiveCode Forums.

I'm tasked with creating an app that:
- Lets the user create/edit articles for clients
- Lets the users create/edit list of clients
- On the single-screen dashboard, articles are displayed in a grid; double-click the row and you can view or edit the article
- Articles belong to a client

In traditional DBMS terms there would be tables for clients and articles. Articles have other info associated with them such as client ID, author of article, etc.

There should be no more than a few thousand articles per database so no external database solution such as SQL is required.

Is this a good structure for the LiveCode app?
- Dashboard is a one-card stack controls for creating, viewing, and editing articles & clients
- Articles are stored in a stack of their own
- Clients are stored in a stack of their own
- Dashboard has a data grid of current articles
- The data grid of current articles is populated from the article stack

If this is an acceptable app architecture, how does one store "relations", for example, how does one include a list of articles written for a client in a client record? Would it be the name of the stack and the card ID of each article?

I have searched fruitlessly for something covering this topic; obviously I'd be grateful for a RTFM comment containing a link to this subject!

tomcam wrote: There should be no more than a few thousand articles per database so no external database solution such as SQL is required.

What about.... a local database with SQLite ?

No need to install a server, it's very handy and simple.

Here are the lessons to start with,

http://lessons.runrev.com/s/lessons/m/4 ... e-database
http://lessons.runrev.com/m/datagrid

Simon

Thank you, Bangkok and Simon. It looks like SQLite is the right way to go. I sort of guessed I would end up there and am quite happy to, since I tend to think in databases. This time I was trying to think in LiveCode instead. No problem reverting to my old ways, though!