Do I really need a database for this ?

Hello,

I try to make a sort of invoice app so I can track if a invoice is send
to a customer.
Later on I will try to add a possibility to keep track if the invoices
are payed or not.

Now I wonder if I really need a database for such a app or if there is
another way so I can host it for
free at seaside ?

Roelof

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You can always use BOSS or xml to store your objects. If you don't need the features of a db, don't use one. This has nothing do do with Smalltalk.

Roelof Wobben <[hidden email]> schrieb:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Roelof,

You can also use Boss or Sixx to write your stuff to a disk, a database is more work but it does have numerous advantages, notably the fact that you write while you work, minimising data loss.

Personally I use both databases including Sqlite files which the end user will see as aplication files as well as Boss. I use the later to write undo and redo information.

 

Good luck

 

@+Maarten,

 

> "Roelof Wobben" <[hidden email]> |

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I have a couple of applications with light-weight data. Meanwhile I have some experience with Glorp which significantly facilitates the task of mapping objects to relational databases. But if the amount of data allows it (let's say less than 10 MB) I still prefer XML or simple text over a relational database. With VisualWorks you have a well working and highly performant webservices framework to serialize/read objects to/from XML file. Sixx is another toolset but I feel it's not as flexible and more complicated to use.

Some advantages of XML: You can read data with any text editor, some have extra support for XML files to facilitate reading. Tools for XPath and XSLT in Smalltalk and many other programming environments can be used to process the data,
Disadvantage: If you cannot find a good modular output structure (e.g. one XML file per invoice) you easily end up with a monolith (all data in one file). That means that each single change (transaction) requires dumping all data. My experience tells that with limited data this won't be a performance problem. Writing a 10 MB XML file is really fast.
Opposed to that, a relational db always writes the changed records only. If you want a multi-user application with concurrent writes, a database might be preferrable.
BOSS is another alternative, but I personally would avoid like hell to use it for persistency. The disadvantages are hard to bear, in particular its monolithic obscure character. You never know what's inside a BOSS stream. Too often I experienced that objects were stored that never were supposed to be. Last not least it is a proprietary format which can only be read by VisualWorks. BOSS is best suited for storing and exchanging data on the fly, with ultimate performance for arbitrarily complex structures, and that's why I love to use it frequently. But I wouldn't like to rely on it for long time persistence.

my 2c

Holger Guhl
-- 
Senior Consultant * Certified Scrum Master * [hidden email]
Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund  A 12812

Am 02.09.2014 08:16, schrieb [hidden email]

Hi Roelof,

You can also use Boss or Sixx to write your stuff to a disk, a database is more work but it does have numerous advantages, notably the fact that you write while you work, minimising data loss.

Personally I use both databases including Sqlite files which the end user will see as aplication files as well as Boss. I use the later to write undo and redo information.

 

Good luck

 

@+Maarten,

 

> "Roelof Wobben" [hidden email] |

> Hello,
>
> I try to make a sort of invoice app so I can track if a invoice is send
> to a customer.
> Later on I will try to add a possibility to keep track if the invoices
> are payed or not.
>
> Now I wonder if I really need a database for such a app or if there is
> another way so I can host it for
> free at seaside ?
>
> Roelof
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

RTFM ;-)
Yes, a good primer is "...\doc\WebServices.pdf" in your VisualWorks installation directory. If you want to have practical experiences, there are demo/example parcels for Webservices where XML/SOAP is used. There is also a parcel XMLObjectBindingWizard which implements a GUI tool to map Smalltalk domain objects into an XML schema and vice versa. The tool generates a Workspace test script that contains the general code fragments to (de)serialize objects from/to XML.

Cheers,
Holger

Am 02.09.2014 13:09, schrieb Roelof Wobben:

Thanks,

Is there anywhere info how I can do the serialize/read the objects.

Roelof



Holger Guhl schreef op 2-9-2014 13:04:

I have a couple of applications with light-weight data. Meanwhile I have some experience with Glorp which significantly facilitates the task of mapping objects to relational databases. But if the amount of data allows it (let's say less than 10 MB) I still prefer XML or simple text over a relational database. With VisualWorks you have a well working and highly performant webservices framework to serialize/read objects to/from XML file. Sixx is another toolset but I feel it's not as flexible and more complicated to use.

Some advantages of XML: You can read data with any text editor, some have extra support for XML files to facilitate reading. Tools for XPath and XSLT in Smalltalk and many other programming environments can be used to process the data,
Disadvantage: If you cannot find a good modular output structure (e.g. one XML file per invoice) you easily end up with a monolith (all data in one file). That means that each single change (transaction) requires dumping all data. My experience tells that with limited data this won't be a performance problem. Writing a 10 MB XML file is really fast.
Opposed to that, a relational db always writes the changed records only. If you want a multi-user application with concurrent writes, a database might be preferrable.
BOSS is another alternative, but I personally would avoid like hell to use it for persistency. The disadvantages are hard to bear, in particular its monolithic obscure character. You never know what's inside a BOSS stream. Too often I experienced that objects were stored that never were supposed to be. Last not least it is a proprietary format which can only be read by VisualWorks. BOSS is best suited for storing and exchanging data on the fly, with ultimate performance for arbitrarily complex structures, and that's why I love to use it frequently. But I wouldn't like to rely on it for long time persistence.

my 2c

Holger Guhl
-- 
Senior Consultant * Certified Scrum Master * [hidden email]
Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund  A 12812

Am 02.09.2014 08:16, schrieb [hidden email]

Hi Roelof,

You can also use Boss or Sixx to write your stuff to a disk, a database is more work but it does have numerous advantages, notably the fact that you write while you work, minimising data loss.

Personally I use both databases including Sqlite files which the end user will see as aplication files as well as Boss. I use the later to write undo and redo information.

 

Good luck

 

@+Maarten,

 

> "Roelof Wobben" [hidden email] |

> Hello,
>
> I try to make a sort of invoice app so I can track if a invoice is send
> to a customer.
> Later on I will try to add a possibility to keep track if the invoices
> are payed or not.
>
> Now I wonder if I really need a database for such a app or if there is
> another way so I can host it for
> free at seaside ?
>
> Roelof
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Roelof Wobben <[hidden email]> schrieb:
>
>I try to make a sort of invoice app so I can track if a invoice is send
>to a customer.
>Later on I will try to add a possibility to keep track if the invoices
>are payed or not.
>
>Now I wonder if I really need a database for such a app or if there is
>another way so I can host it for free at seaside ?
>


It is worth pointing out the balancing act you need for data management in
any application. In any case, there is a certain amount of work you will
need to do. Analysis of that work will tell you what solutions are suitable
for your needs.

At one end of the spectrum, you can go with a "roll your own" solution. This
requires a fairly simple data model, data volume, and retrieval
requirements.

At "the" other end of the spectrum, you can go with a database solution.
Typically, this will be when your model is more complex, you have higher
data volumes, or you have more elaborate retrieval requirements.

-----------------
With the simpler, roll your own, you have to do all the data management
work. Additionally, you probably need to be careful of data migration
issues. Unless you know your data model is finished and will not evolve, you
want to be able to support having both old and new formats. A simple
structure replication model may cause a lot of headache if you evolve your
model (or refactor anything, etc.). I believe JSON, SIXX, and XML all
replicate the structure rather than a logical model. You should consider
implementing #storeOn: to write out a logical representation of your model
as a fairly compact Smalltalk expression that can be evaluated to read the
data.

With relational databases, there is a substantial overhead in the object to
relational mapping. But that is offset by the number of different databases
you can choose from. Again, data migration is a concern.

There are also object databases. The only one I am familiar with is
GemStone. With GemStone, your object model *is* Smalltalk all the way, all
the time. Add an item to a persistent collection, commit, and you're done.
You can easily add indexes as your application grows. Likewise, if you want
to model your customers, the object references from the invoice are simple
and automatic.

<commercial-plug>
GemStone has a free - even for commercial use - license and has a Seaside
implementation. There is community support for it with a great bunch of
people contributing and helping others. A number of people use the "build in
Pharo, deploy in GemStone" approach. But you can develop and deploy solely
in GemStone.

You can find more information at
http://gemtalksystems.com/index.php/products/glass-seaside/.
<\commercial-plug>



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc