Database Relationships

[dunbarx]

hi.

Livecode is an "xTalk", derived from a older Apple program called Hypercard. It is very easy to learn, very powerful, but has it own style and methods. It supports certain databases, and can itself be configured as a database, but is not a database per se.

Best to start by reading the resident user and beginner guides in the "Help" menu. I always say to try to make a simple program, like an address book or calculator, neither of which will likely be very pretty, nor even particularly useful later on. But the exercise will be priceless, and greatly speed up your learning curve.

You have to get started to a certain extent on your own. There are many other sites where a new user can get guidance. This forum is eager to help anyone at any level. You might even search for the word "database" when you have a little experience, to see what others have done in that arena. There is quite a lot there, by the way.

So get going. Ask your questions. The learning curve is not steep, but also not trivial.

Craig

[dunbarx]

Your question about cards and stacks is fundamental. As an xTalk, the structure of LiveCode is that of a "stack", which is invariably the "base" window, and which may contain one or many cards. One may navigate through those cards similarly to a rolodex. But many of my programs contain only a single card.

The LiveCode model covers all possible setups within that paradigm. This all depends on what you are building.

Craig

[FourthWorld]

I am used to working in filemaker and just downloaded livecode to learn it.
Dont uderstand where the relationships with one to one and one to many comes into the cards and stacks.

They don't. Cards and stacks are user interface elements, much like layouts in FileMaker. They can be used to store data, but binding data to the UI that presents it is not a recommended practice. It can be okay for relatively small (<5000) flat records, but bigger data bound to UI objects can slow searches and saves, and the object model does not attempt to mimic a relational DB.

Data storage options in LC are vast, from flat files, delimited files, JSON, LSON, and interfaces to the world's leading data storage solutions from SQLite, MySQL, MariaDB, postgreSQL, Oracle, and even CouchDB.

Since you're coming from a relational DB you'll have the easiest time using relational storage from LC, most commonly SQLite for local data and MySQL or MariaDB for remote.

[stam]

I am used to working in filemaker and just downloaded livecode to learn it.
Dont uderstand where the relationships with one to one and one to many comes into the cards and stacks.

Fortunately or unfortunately, liveCode - as practically every other programming language out there - is different from FMP inasmuch as there is no built-in database as there is with FMP. That means more work to get simple stuff done but also much more flexibility.

FMP is a great environment for rapid database development, but the pricing model if difficult for most smaller devs. It's great because everything is directly linked into your DB and you can design the DB directly inside the same app. But this is quite uncommon amongst other programming environments, where there is a clear separation from 'the database' and 'the app', and you have to program the 'connection' so the two can speak to each other. This is what FMP shields you from, but which is commonplace in every other programming environment.

The first step is to decide if you actually need a database as such - LiveCode is great at storing data as it is, and although not as efficient as a DBMS it may suffice; or perhaps storing as a text file (eg TSV) or binary array file may suffice.

If need want a database-driven app, you should first consider what database this will be running (eg sqlite, MySQL, oracle, anything via ODBC - or a noSQL db such as couchDB or have a look at LiveCloud.io) and design your database first (typically for single user databases SQLite is the db of choice).

Then you need to create your app that will reference the database. It's a much more complex affair than creating an 'app' in FMP - but you create a royalty free app with many more features and flexibility.

'Cards' and 'Stacks' is a different concept altogether, not related to databases directly - think of the stack as your 'app' and cards as the 'windows' of your app - it's of course not exactly that simple but as a rough approximation... You can use the cards of a stack as a kind of database but for most cases where a database is needed you'll need to consider one of the above options.

If you have no experience with SQL or noSQL database app development, there will be a non-trivial learning curve, but once you've mastered that you'll be much happier and less constrained than with FMP...