Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28352 > unrolled thread

simple client data base

Back to article view | Back to comp.lang.python

Contents

  simple client data base Mark R Rivet <markrrivet@aol.com> - 2012-09-03 10:12 -0400
    Re: simple client data base "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-09-03 07:27 -0700
    Re: simple client data base Chris Angelico <rosuav@gmail.com> - 2012-09-04 00:28 +1000
    Re: simple client data base Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-03 15:37 +0100
    Re: simple client data base Peter Otten <__peter__@web.de> - 2012-09-03 16:50 +0200
      Re: simple client data base Mark R Rivet <markrrivet@aol.com> - 2012-09-08 15:22 -0400
        Re: simple client data base Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-08 17:42 -0400
    Re: simple client data base Wolfgang Keller <feliphil@gmx.net> - 2012-09-03 18:03 +0200
      Re: simple client data base Walter Hurry <walterhurry@lavabit.com> - 2012-09-03 19:02 +0000
        Re: simple client data base Wolfgang Keller <feliphil@gmx.net> - 2012-09-04 15:17 +0200
    Re: simple client data base Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-04 04:25 +0200
      Re: simple client data base Mark R Rivet <markrrivet@aol.com> - 2012-09-08 15:40 -0400
        Re: simple client data base Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-11 13:28 +0200
    Re: simple client data base Ramchandra Apte <maniandram01@gmail.com> - 2012-09-05 05:57 -0700
      Re: simple client data base Mark R Rivet <markrrivet@aol.com> - 2012-09-08 15:42 -0400
    Re: simple client data base Bryan <bryanjugglercryptographer@yahoo.com> - 2012-09-06 01:57 -0700
      Re: simple client data base Mark R Rivet <markrrivet@aol.com> - 2012-09-08 15:47 -0400
        Re: simple client data base Jason Friedman <jason@powerpull.net> - 2012-09-08 14:05 -0600
        Re: simple client data base Paul Rubin <no.email@nospam.invalid> - 2012-09-08 13:11 -0700
          Re: simple client data base Ian W <mymixedmess@gmail.com> - 2012-09-08 15:32 -0500
          Re: simple client data base Walter Hurry <walterhurry@lavabit.com> - 2012-09-08 20:39 +0000
        Re: simple client data base Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-09-08 21:03 +0000
        Re: simple client data base Bryan <bryanjugglercryptographer@yahoo.com> - 2012-09-09 09:06 -0700
        Re: simple client data base Tim Chase <python.list@tim.thechases.com> - 2012-09-09 13:27 -0500
          Re: simple client data base Paul Rubin <no.email@nospam.invalid> - 2012-09-09 11:55 -0700

Page 1 of 2  [1] 2  Next page →

#28352 — simple client data base

Hello all, I am learning to program in python. I have a need to make a
program that can store, retrieve, add, and delete client data such as
name, address, social, telephone number and similar information. This
would be a small client database for my wife who has a home accounting
business.

I have been reading about lists, tuples, and dictionary data
structures in python and I am confused as to which would be more
appropriate for a simple database.

I know that python has real database capabilities but I'm not there
yet and would like to proceed with as simple a structure as possible.

Can anyone give me some idea's or tell me which structure would be
best to use?

Maybe its a combination of structures? I need some help.

Thanks for your help.

[toc] | [next] | [standalone]

#28353

On Monday, 3 September 2012 15:12:21 UTC+1, Manatee  wrote:
> Hello all, I am learning to program in python. I have a need to make a
> 
> program that can store, retrieve, add, and delete client data such as
> 
> name, address, social, telephone number and similar information. This
> 
> would be a small client database for my wife who has a home accounting
> 
> business.
> 
> 
> 
> I have been reading about lists, tuples, and dictionary data
> 
> structures in python and I am confused as to which would be more
> 
> appropriate for a simple database.
> 
> 
> 
> I know that python has real database capabilities but I'm not there
> 
> yet and would like to proceed with as simple a structure as possible.
> 
> 
> 
> Can anyone give me some idea's or tell me which structure would be
> 
> best to use?
> 
> 
> 
> Maybe its a combination of structures? I need some help.
> 
> 
> 
> Thanks for your help.

How about the half-way house, sqlite3 which comes with python?

hth
-- 
mph

[toc] | [prev] | [next] | [standalone]

#28354

On Tue, Sep 4, 2012 at 12:12 AM, Mark R Rivet <markrrivet@aol.com> wrote:
> I have been reading about lists, tuples, and dictionary data
> structures in python and I am confused as to which would be more
> appropriate for a simple database.

I think you're looking at this backwards. A database is for storing
information on disk, but lists/tuples/dicts are for manipulating it in
memory.

You may also be needlessly reinventing the wheel. Aren't there already
several million basic contact databases around? Why roll your own?

ChrisA

[toc] | [prev] | [next] | [standalone]

#28355

On 03/09/2012 15:12, Mark R Rivet wrote:
> Hello all, I am learning to program in python. I have a need to make a
> program that can store, retrieve, add, and delete client data such as
> name, address, social, telephone number and similar information. This
> would be a small client database for my wife who has a home accounting
> business.
>
> I have been reading about lists, tuples, and dictionary data
> structures in python and I am confused as to which would be more
> appropriate for a simple database.
>
> I know that python has real database capabilities but I'm not there
> yet and would like to proceed with as simple a structure as possible.
>
> Can anyone give me some idea's or tell me which structure would be
> best to use?
>
> Maybe its a combination of structures? I need some help.
>
> Thanks for your help.
>

If you stick with the simple data structures at some point you're going 
to have to save them to disk with a module like pickle or shelve.  IMHO 
using sqlite is a better option as it comes with Python.

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#28356

Chris Angelico wrote:

> You may also be needlessly reinventing the wheel. Aren't there already
> several million basic contact databases around? Why roll your own?

To learn a thing or two, and to stick it to the defeatists ;)

[toc] | [prev] | [next] | [standalone]

#28733

On Mon, 03 Sep 2012 16:50:14 +0200, Peter Otten <__peter__@web.de>
wrote:

>Chris Angelico wrote:
>
>> You may also be needlessly reinventing the wheel. Aren't there already
>> several million basic contact databases around? Why roll your own?
>
>To learn a thing or two, and to stick it to the defeatists ;)
Yes, that's the reason. I need to learn something. Without getting
into the complexities of relational database's for now.

[toc] | [prev] | [next] | [standalone]

#28747

On Sat, 08 Sep 2012 15:22:24 -0400, Mark R Rivet <markrrivet@aol.com>
declaimed the following in gmane.comp.python.general:

> Yes, that's the reason. I need to learn something. Without getting
> into the complexities of relational database's for now.

	Given the ease of use of SQLite3, I think you'd be better served by
using an RDBM rather then try to manage persistence of Python in-memory
objects (pickle is not guaranteed to be compatible between versions of
Python; and for all these schemes you become responsible for loading and
saving a block of data using Python level instructions. RDBM interfaces
normally take care of translating the low-level entities between Python
and database format; you don't have to develop search and filter logic
to manage subsets of the data, etc.).

	There is even a plugin for Mozilla -- SQLite Manager -- since
Mozilla uses SQLite3 internally, which can give you rudimentary
graphical access to raw databases (so you can debug the data in the
database while developing the application code to "properly" access the
data).

	Dabo is attempting to be a Python "Visual FoxPro" equivalent.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#28362

> Hello all, I am learning to program in python. I have a need to make a
> program that can store, retrieve, add, and delete client data such as
> name, address, social, telephone number and similar information. This
> would be a small client database for my wife who has a home accounting
> business.

<hint>

Python imho would be in need of a really good accounting application as
a "demonstrator" for its capabilities. ;-)

</hint>

> I have been reading about lists, tuples, and dictionary data
> structures in python and I am confused as to which would be more
> appropriate for a simple database.
> 
> I know that python has real database capabilities but I'm not there
> yet and would like to proceed with as simple a structure as possible.

The list of Python frameworks for rapid development of desktop
(i.e. non-Web) database applications currently contains:

using PyQt (& Sqlalchemy):
Pypapi: www.pypapi.org
Camelot: www.python-camelot.com
Qtalchemy: www.qtalchemy.org

using PyGTK:
Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
Kiwi: www.async.com.br/projects/kiwi

using wxPython:
Dabo: www.dabodev.com
Defis: sourceforge.net/projects/defis (Russian only)
GNUe: www.gnuenterprise.org

Pypapi, Camelot, Sqlkit and Dabo seem to be the most active and best
documented/supported ones.

Sqlalchemy (www.sqlalchemy.org) seems to be "quite useful" for working
with databases. Those of the above mentioned frameworks that don't use
it do so for historic reasons, because the corresponding project started
before Sqlalchemy became known.

If you want to rely on not losing your data, you might want to use
PostgreSQL (www.postgresql.org) as a storage backend with any of these.

Sincerely,

Wolfgang

P.S.: If anyone knows of frameworks not listed here, thanks for mailing
me.

[toc] | [prev] | [next] | [standalone]

#28365

On Mon, 03 Sep 2012 18:03:27 +0200, Wolfgang Keller wrote:

>> Hello all, I am learning to program in python. I have a need to make a
>> program that can store, retrieve, add, and delete client data such as
>> name, address, social, telephone number and similar information. This
>> would be a small client database for my wife who has a home accounting
>> business.
> 
> <hint>
> 
> Python imho would be in need of a really good accounting application as
> a "demonstrator" for its capabilities. ;-)
> 
> </hint>
> 
>> I have been reading about lists, tuples, and dictionary data structures
>> in python and I am confused as to which would be more appropriate for a
>> simple database.
>> 
>> I know that python has real database capabilities but I'm not there yet
>> and would like to proceed with as simple a structure as possible.
> 
> The list of Python frameworks for rapid development of desktop (i.e.
> non-Web) database applications currently contains:
> 
> using PyQt (& Sqlalchemy):
> Pypapi: www.pypapi.org Camelot: www.python-camelot.com Qtalchemy:
> www.qtalchemy.org
> 
> using PyGTK:
> Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
> Kiwi: www.async.com.br/projects/kiwi
> 
> using wxPython:
> Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian
> only)
> GNUe: www.gnuenterprise.org
> 
> Pypapi, Camelot, Sqlkit and Dabo seem to be the most active and best
> documented/supported ones.
> 
> Sqlalchemy (www.sqlalchemy.org) seems to be "quite useful" for working
> with databases. Those of the above mentioned frameworks that don't use
> it do so for historic reasons, because the corresponding project started
> before Sqlalchemy became known.
> 
> If you want to rely on not losing your data, you might want to use
> PostgreSQL (www.postgresql.org) as a storage backend with any of these.

Personally, I wouldn't bother with SQLAlchemy for this. I'd just use 
Python as the front end, PostgreSQL for the database, and psycopg2 for 
the interface.

[toc] | [prev] | [next] | [standalone]

#28401

> Personally, I wouldn't bother with SQLAlchemy for this. I'd just use 
> Python as the front end, PostgreSQL for the database, and psycopg2
> for the interface.

Then you have to implement the entire logic, "event binding" etc.
yourself. 

If you use e.g. Pypapi (the latest version), implementing an entire
CRUD application is as simple as declaring your domain object model and
laying out your GUI with Qt Designer.

In Sqlkit, you don't have to do much more, you just don't use a
designer for the GUI, but also a declarative approach.

Sincerely,

Wolfgang

[toc] | [prev] | [next] | [standalone]

#28385

Mark R Rivet wrote:

> Hello all, I am learning to program in python. I have a need to make a
> program that can store, retrieve, add, and delete client data such as
> name, address, social, telephone number and similar information. This
> would be a small client database for my wife who has a home accounting
> business.
> 
> I have been reading about lists, tuples, and dictionary data
> structures in python and I am confused as to which would be more
> appropriate for a simple database.
> 
> I know that python has real database capabilities but I'm not there
> yet and would like to proceed with as simple a structure as possible.
> 
> Can anyone give me some idea's or tell me which structure would be
> best to use?
> 
> Maybe its a combination of structures? I need some help.

The data types that would choose are defined by your requirements and how 
well a data type meets your requirements.

I can imagine: In a database you would want quick access to data.  You would 
want to access fields primarily by name.  You would also want to filter data 
by various criteria.

Therefore, it appears to me that it would be best if your records were 
dictionaries or dictionary-like objects, and your recordsets were lists of 
records, like so

#!/usr/bin/env python3

from datetime import date

data = [
  {
    'lastname':  'Doe',
    'firstname': 'John',
    'sn':        '123-451-671-890',
    'birthdata': date(2000, 1, 2)
  },
  {
    'lastname':  'Doe',
    'firstname': 'Jane',
    'sn':        '409-212-582-452',
    'birthdata': date(2001, 2, 3)
 },
]

- You could quickly access the second record with data[1].
- You could access the 'lastname' field of the second record with
  data[1]['lastname']
- You could get a list of records where the person is born before 2001 CE
  with filter(lambda record: record['birthdate'] < date(2001, 1, 1), data)

The advantage of dictionaries over dictionary-like objects is that they are 
easily extensible and that the memory footprint is probably lower (CMIIW); 
the disadvantage is slightly more complicated syntax and that you have to 
keep track of the keys.  Therefore, you might want to consider instantiating 
a Record class instead; in its simplest form:

class Record(object):
  def __init__(self, lastname, firstname, sn=None, birthdate=None):
    self.lastname = lastname
    self.firstname = firstname
    self.sn = str(sn)
    self.birthdate = birthdate

data = [
  Record(lastname='Doe', firstname='John', sn='123-451-671-890',
         birthdate=date(2000, 1, 2)),	
  Record(lastname='Doe', firstname='Jane', sn='409-212-582-452',
         birthdate=date(2001, 2, 3))
]

- You could access the 'lastname' property of the second record with
  data[1].lastname
- You get a list of records where the person is born before 2001 CE with
  list(filter(lambda record: record.birthdate < date(2001, 1, 1), data))
  (in Python 2.x without list())

However, if you want your program to manipulate the data *persistently*. as 
it will probably be needed for business, you will need to also store it 
somewhere else than in the volatile memory in which these data structures 
are usually stored.  The most simple way would be to store and parse the 
string representation of the objects.

Production-quality implementations of those and other concepts already 
exist, of course, but using something finished and polished does not provide 
as much learning experience.

HTH

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28734

On Tue, 04 Sep 2012 04:25:14 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Mark R Rivet wrote:
>
>> Hello all, I am learning to program in python. I have a need to make a
>> program that can store, retrieve, add, and delete client data such as
>> name, address, social, telephone number and similar information. This
>> would be a small client database for my wife who has a home accounting
>> business.
>> 
>> I have been reading about lists, tuples, and dictionary data
>> structures in python and I am confused as to which would be more
>> appropriate for a simple database.
>> 
>> I know that python has real database capabilities but I'm not there
>> yet and would like to proceed with as simple a structure as possible.
>> 
>> Can anyone give me some idea's or tell me which structure would be
>> best to use?
>> 
>> Maybe its a combination of structures? I need some help.
>
>The data types that would choose are defined by your requirements and how 
>well a data type meets your requirements.
>
>I can imagine: In a database you would want quick access to data.  You would 
>want to access fields primarily by name.  You would also want to filter data 
>by various criteria.
>
>Therefore, it appears to me that it would be best if your records were 
>dictionaries or dictionary-like objects, and your recordsets were lists of 
>records, like so
>
>#!/usr/bin/env python3
>
>from datetime import date
>
>data = [
>  {
>    'lastname':  'Doe',
>    'firstname': 'John',
>    'sn':        '123-451-671-890',
>    'birthdata': date(2000, 1, 2)
>  },
>  {
>    'lastname':  'Doe',
>    'firstname': 'Jane',
>    'sn':        '409-212-582-452',
>    'birthdata': date(2001, 2, 3)
> },
>]
>
>- You could quickly access the second record with data[1].
>- You could access the 'lastname' field of the second record with
>  data[1]['lastname']
>- You could get a list of records where the person is born before 2001 CE
>  with filter(lambda record: record['birthdate'] < date(2001, 1, 1), data)
>
>The advantage of dictionaries over dictionary-like objects is that they are 
>easily extensible and that the memory footprint is probably lower (CMIIW); 
>the disadvantage is slightly more complicated syntax and that you have to 
>keep track of the keys.  Therefore, you might want to consider instantiating 
>a Record class instead; in its simplest form:
>
>class Record(object):
>  def __init__(self, lastname, firstname, sn=None, birthdate=None):
>    self.lastname = lastname
>    self.firstname = firstname
>    self.sn = str(sn)
>    self.birthdate = birthdate
>
>data = [
>  Record(lastname='Doe', firstname='John', sn='123-451-671-890',
>         birthdate=date(2000, 1, 2)),	
>  Record(lastname='Doe', firstname='Jane', sn='409-212-582-452',
>         birthdate=date(2001, 2, 3))
>]
>
>- You could access the 'lastname' property of the second record with
>  data[1].lastname
>- You get a list of records where the person is born before 2001 CE with
>  list(filter(lambda record: record.birthdate < date(2001, 1, 1), data))
>  (in Python 2.x without list())
>
>However, if you want your program to manipulate the data *persistently*. as 
>it will probably be needed for business, you will need to also store it 
>somewhere else than in the volatile memory in which these data structures 
>are usually stored.  The most simple way would be to store and parse the 
>string representation of the objects.
>
>Production-quality implementations of those and other concepts already 
>exist, of course, but using something finished and polished does not provide 
>as much learning experience.
>
>HTH
Now this is the kind of answer I was hoping for. This gives me food
for thought. Now I have some Ideas of how to appproach this thing. I
know that there are solutions to this problem already but I need to do
my own before I can really use anything better. Thanks for the help. I
fully intend to go with a real realational database, but not now. My
version 1 will be a console interface and dictionaries, lists and
pickling. Version 2 will be with a GUI written in tkinter, and better
and better. I just want to learn how to lay the bricks before I start
using prefab walls.

[toc] | [prev] | [next] | [standalone]

#28884

Mark R Rivet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Mark R Rivet wrote:
>>> Hello all, I am learning to program in python. I have a need to make a
>>> program that can store, retrieve, add, and delete client data such as
>>> name, address, social, telephone number and similar information. This
>>> would be a small client database for my wife who has a home accounting
>>> business.
>>> 
>>> I have been reading about lists, tuples, and dictionary data
>>> structures in python and I am confused as to which would be more
>>> appropriate for a simple database.
>> 
>> […]
>> However, if you want your program to manipulate the data *persistently*.
>> as it will probably be needed for business, you will need to also store
>> it somewhere else than in the volatile memory in which these data
>> structures are usually stored.  The most simple way would be to store and
>> parse the string representation of the objects.
>>
>> Production-quality implementations of those and other concepts already
>> exist, of course, but using something finished and polished does not
>> provide as much learning experience.
> 
> Now this is the kind of answer I was hoping for. This gives me food
> for thought. Now I have some Ideas of how to appproach this thing. I
> know that there are solutions to this problem already but I need to do
> my own before I can really use anything better. Thanks for the help. I
> fully intend to go with a real realational database, but not now. My
> version 1 will be a console interface and dictionaries, lists and
> pickling. Version 2 will be with a GUI written in tkinter, and better
> and better. I just want to learn how to lay the bricks before I start
> using prefab walls.

You are welcome.  However, I have to concur with the others that in terms of 
efficiency and reliability, which leads to household peace, you are better 
off starting with a prepackaged solution instead.

You can keep developing your Python-powered database as a pet project for 
the time being.  Your wife will be even more impressed if at one day you can 
tell her that you wrote completely customizable software that works the same 
or even better than the one she has been getting used to :)  Even if not, 
you will have learned much about Python and related concepts along the way.  
Keep in mind, then, that you probably also need a graphical user interface.

Please trim your quotes to the relevant minimum next time.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28487

On Monday, 3 September 2012 19:42:21 UTC+5:30, Manatee  wrote:
> Hello all, I am learning to program in python. I have a need to make a
> 
> program that can store, retrieve, add, and delete client data such as
> 
> name, address, social, telephone number and similar information. This
> 
> would be a small client database for my wife who has a home accounting
> 
> business.
> 
> 
> 
> I have been reading about lists, tuples, and dictionary data
> 
> structures in python and I am confused as to which would be more
> 
> appropriate for a simple database.
> 
> 
> 
> I know that python has real database capabilities but I'm not there
> 
> yet and would like to proceed with as simple a structure as possible.
> 
> 
> 
> Can anyone give me some idea's or tell me which structure would be
> 
> best to use?
> 
> 
> 
> Maybe its a combination of structures? I need some help.
> 
> 
> 
> Thanks for your help.

If there are not more than 1000 records you can just use `pickle`

[toc] | [prev] | [next] | [standalone]

#28735

On Wed, 5 Sep 2012 05:57:24 -0700 (PDT), Ramchandra Apte
<maniandram01@gmail.com> wrote:

>On Monday, 3 September 2012 19:42:21 UTC+5:30, Manatee  wrote:
>> Hello all, I am learning to program in python. I have a need to make a
>> 
>> program that can store, retrieve, add, and delete client data such as
>> 
>> name, address, social, telephone number and similar information. This
>> 
>> would be a small client database for my wife who has a home accounting
>> 
>> business.
>> 
>> 
>> 
>> I have been reading about lists, tuples, and dictionary data
>> 
>> structures in python and I am confused as to which would be more
>> 
>> appropriate for a simple database.
>> 
>> 
>> 
>> I know that python has real database capabilities but I'm not there
>> 
>> yet and would like to proceed with as simple a structure as possible.
>> 
>> 
>> 
>> Can anyone give me some idea's or tell me which structure would be
>> 
>> best to use?
>> 
>> 
>> 
>> Maybe its a combination of structures? I need some help.
>> 
>> 
>> 
>> Thanks for your help.
>
>If there are not more than 1000 records you can just use `pickle`
Yes, not more than a 1000. My wifes clients only number 300. So not
much of a problem for now I guess. I can't see it growing to double
that, because 300 clients takes alot of work as it is.

[toc] | [prev] | [next] | [standalone]

#28559

Mark R Rivet wrote:
> Hello all, I am learning to program in python. I have a need to make a
> program that can store, retrieve, add, and delete client data such as
> name, address, social, telephone number and similar information. This
> would be a small client database for my wife who has a home accounting
> business.

Among programming languages Python is exceptionally easy to learn, and
rocks for the kind of app you describe, but your goal is not
realistic. Simple is better than complex, but what you can build at
this point is far from what a professional accountant with her own
business needs from a client database manager.

> I have been reading about lists, tuples, and dictionary data
> structures in python and I am confused as to which would be more
> appropriate for a simple database.

Those are good classes to read about, and I dare say that most
Pythoneers at some time faced confusion as to which were most
appropriate for the problem at hand. You'd need of all them and more,
a whole freak'in bunch more, to build a professional quality contact
manager app.

> I know that python has real database capabilities but I'm not there
> yet and would like to proceed with as simple a structure as possible.
>
> Can anyone give me some idea's or tell me which structure would be
> best to use?
>
> Maybe its a combination of structures? I need some help.

comp.lang.python tries to be friendly and helpful, and to that end
responders have read and answered your question as directly as
possible. There's good stuff available for Python.

Mark, there is absolutely no chance, no how, no way, that your stated
plan is a good idea. Fine CRM apps are available for free; excellent
ones for a few dollars. You're reading about lists, tuples, and
dictionary data? Great, but other home accounting businesses have
their client databases automatically synced with their smart-phones
and their time-charging and their invoicing.

-Bryan

[toc] | [prev] | [next] | [standalone]

#28736

On Thu, 6 Sep 2012 01:57:04 -0700 (PDT), Bryan
<bryanjugglercryptographer@yahoo.com> wrote:

>Mark R Rivet wrote:
>> Hello all, I am learning to program in python. I have a need to make a
>> program that can store, retrieve, add, and delete client data such as
>> name, address, social, telephone number and similar information. This
>> would be a small client database for my wife who has a home accounting
>> business.
>
>Among programming languages Python is exceptionally easy to learn, and
>rocks for the kind of app you describe, but your goal is not
>realistic. Simple is better than complex, but what you can build at
>this point is far from what a professional accountant with her own
>business needs from a client database manager.
>
>> I have been reading about lists, tuples, and dictionary data
>> structures in python and I am confused as to which would be more
>> appropriate for a simple database.
>
>Those are good classes to read about, and I dare say that most
>Pythoneers at some time faced confusion as to which were most
>appropriate for the problem at hand. You'd need of all them and more,
>a whole freak'in bunch more, to build a professional quality contact
>manager app.
>
>> I know that python has real database capabilities but I'm not there
>> yet and would like to proceed with as simple a structure as possible.
>>
>> Can anyone give me some idea's or tell me which structure would be
>> best to use?
>>
>> Maybe its a combination of structures? I need some help.
>
>comp.lang.python tries to be friendly and helpful, and to that end
>responders have read and answered your question as directly as
>possible. There's good stuff available for Python.
>
>Mark, there is absolutely no chance, no how, no way, that your stated
>plan is a good idea. Fine CRM apps are available for free; excellent
>ones for a few dollars. You're reading about lists, tuples, and
>dictionary data? Great, but other home accounting businesses have
>their client databases automatically synced with their smart-phones
>and their time-charging and their invoicing.
>
>-Bryan
Well I have to say that this is most discouraging. I should give up
learning to program. I don't have a chance at all. Thanks.

[toc] | [prev] | [next] | [standalone]

#28738

>>Mark R Rivet wrote:
>>> Hello all, I am learning to program in python. I have a need to make a
>>> program that can store, retrieve, add, and delete client data such as
>>> name, address, social, telephone number and similar information. This
>>> would be a small client database for my wife who has a home accounting
>>> business.
>>
>>Among programming languages Python is exceptionally easy to learn, and
>>rocks for the kind of app you describe, but your goal is not
>>realistic. Simple is better than complex, but what you can build at
>>this point is far from what a professional accountant with her own
>>business needs from a client database manager.

I am married, and I wonder what his wife will think if she discovers
that she could have had her solution yesterday.  My wife would not
tolerate the roll-your-own approach, but every marriage is different.

[toc] | [prev] | [next] | [standalone]

#28740

Mark R Rivet <markrrivet@aol.com> writes:
>>ones for a few dollars. You're reading about lists, tuples, and
>>dictionary data? Great, but other home accounting businesses have
>>their client databases automatically synced with their smart-phones
>>and their time-charging and their invoicing.
> Well I have to say that this is most discouraging. I should give up
> learning to program. I don't have a chance at all. Thanks.

I think the idea is just to start with something simpler.  If you are
interested in mechanical engineering, then building an automobile from
scratch, machining all the parts yourself etc., would be an ill-advised
choice as a first project.  It's the same way with programming.

[toc] | [prev] | [next] | [standalone]

#28742

On Sat, Sep 8, 2012 at 3:11 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> I think the idea is just to start with something simpler.  If you are
> interested in mechanical engineering, then building an automobile from
> scratch, machining all the parts yourself etc., would be an ill-advised
> choice as a first project.  It's the same way with programming.

I'm wondering what his backup plan is for the information, in case his
database somehow messes things up. It's smarter to start with
something that's not vital to the functioning of your wife's business.

Ian

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web