[Asterisk-Dev] Re: Creating An Asterisk Data Model
James H. Thompson
jht at lj.net
Sun Jun 6 12:06:52 MST 2004
Nice drawing.
If its going to be a general data model it would be great if it accomodated:
One person with multiple phones at the same address
One person with multiple addresses each with possible multiple phone numbers
One person that works for multiple companies
One company with multiple locations each with possible multiple phone numbers.
Since there are muliple symbol sets in use for drawing ER diagrams, perhaps it would be nice to
include a symbol key at the bottom of the drawing. (e.g. solid filled circle = ?)
Jim
James H. Thompson
jht at lava.net
----- Original Message -----
From: "Paul Mahler" <pmahler at signate.com>
To: <asterisk-dev at lists.digium.com>
Sent: Sunday, June 06, 2004 5:15 AM
Subject: RE: Re[2]: [Asterisk-Dev] Re: Creating An Asterisk Data Model
> Hi,
>
> Hibernate is a tool to do object-relational mapping, not a data modeling
> tool. What is needed first is a data model, as steve started on.
>
> I have attached a piece of my ER data model as an example.
>
> Paul
>
>
> Paul Mahler
> pmahler at signate.com
> Signate, LLC
> 665 Third Street
> Suite 100
> San Francisco, CA
> 94107-1901
>
> Asterisk Services and Training
>
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: asterisk-dev-admin at lists.digium.com
> > [mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of
> > Miroslav Nachev
> > Sent: Saturday, June 05, 2004 11:15 PM
> > To: Paul Mahler
> > Subject: Re[2]: [Asterisk-Dev] Re: Creating An Asterisk Data Model
> >
> > Hi,
> >
> > What do you think about some management & configuration
> > program using Java. I mean that we can do the data model
> > using Hibernate which data model use XML as description and
> > Hibernate supports more than 15 popular databases like MySQL,
> > MS SQL Server, Oracle, Informix, DB2, PostgreSQL, HSQL and
> > etc. The creation of database, tables, primary keys, foreign
> > keys, indexes, and population is automaticaly from Hibernate.
> > If some changes are made in XML description file Hibernate
> > automaticaly correct the database model.
> > If we do in details the user/technical requirements I can
> > start working for this and other concerning management and
> > configuration.
> >
> >
> > Best Regards,
> > Miroslav Nachev
> >
> > I'm working on a data model, too. Steve has shared his model
> > with me. I am doing The ER model right now.
> >
> >
> > Paul Mahler
> > pmahler at signate.com
> > Signate, LLC
> > 665 Third Street
> > Suite 100
> > San Francisco, CA
> > 94107-1901
> >
> > Asterisk Services and Training
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: asterisk-dev-admin at lists.digium.com
> > > [mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of
> > Peter Nixon
> > > Sent: Saturday, June 05, 2004 2:58 AM
> > > To: asterisk-dev at lists.digium.com
> > > Subject: [Asterisk-Dev] Re: Creating An Asterisk Data Model
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Saturday 29 May 2004 02:20, Ray Burkholder wrote:
> > > > I've been working on implementing such a project. The
> > > basics for much
> > > > of this stuff is in place.
> > > >
> > > > I have the basic double entry accounting tables in place
> > > for handling
> > > > sales orders, invoicing, shopping cart, AR, AP, GL.
> > > >
> > > > Basic telephony tables are in place to handle atomic
> > > services such as
> > > > origination, termination, did numbers, corporate dial plan, per
> > > > extension feature handling, voicemail, etc. There is a
> > > then a 'package'
> > > > table that allows a mix and match of atomic services to
> > > make a service
> > > > provider offering.
> > > >
> > > > A user self-provisions various services through a web based
> > > interface.
> > > > Services are selected and placed on an order, then
> > invoiced. In a
> > > > prepaid scenario, and deposit has to be applied before
> > provisioning
> > > > takes place. On post paid accounts, provisioning can
> > > happen right away.
> > > >
> > > > Provisioning is simply a matter of enabling the atomic services
> > > > selected via the package.
> > > >
> > > > Incoming calls are directed via a double AGI step, the first
> > > > identifies the inbound DID and it's generic call processing
> > > script.
> > > > That specific script is then started to handle the
> > > specifics of that
> > > > DID's 'character'.
> > > >
> > > > Termination is handled in a similar manner. There are
> > > various calling
> > > > plans to which one may subscribe. The context:script
> > handling that
> > > > terminating call authorizes the termination if the account
> > > is active,
> > > > otherwise not if it is suspended or some such. Then the
> > > appropriate
> > > > rating table is pulled up to rate and route the call.
> > > >
> > > > At call completion, a manager interface pulls out the cdr,
> > > figures out
> > > > the account and service type, and throws it into a sales order.
> > > > Account status is updated at this time to reflect balances
> > > available
> > > > for further calls and such.
> > > >
> > > > The user can review their sales orders and invoices at
> > any time and
> > > > apply payments. On a regular basis, the system post sales
> > > orders to
> > > > invoices and submits email reminders for payments.
> > > >
> > > > Accounting is built in but I've been considering
> > > accelerating that by
> > > > connecting up with open source accounting such as Compiere.
> > > >
> > > > The solution runs on a minimum of 3+n servers. A base system is
> > > > composed of:
> > > > * SQL server, currently PostgreSQL
> > > > * Apache web server running a bunch of Mason/Perl scripts
> > > > * Asterisk server with ip and tdm termination and more
> > Perl call
> > > > processing scripts
> > > >
> > > > All scripts and configurations are CVS'd to facilitate server
> > > > rebuilding and expansion.
> > >
> > > - --snip--
> > >
> > > > Now the question that comes to my mind is that it would be
> > > interesting
> > > > to share the solution as alpha as it may be in order to
> > accelerate
> > > > development and improvement, but still be able to glean
> > > some dollars
> > > > off it.
> > > >
> > > > That is a hard question.
> > >
> > > It is, but as you, Steven and myself all appear to be independently
> > > working towards similar goals, it makes sense to chare the code. I
> > > think you choices of both Postgres and perl are good ones
> > and Compiere
> > > is a good idea, although something that I have currently
> > left out on
> > > the grounds that I don't know enough about accounting systems :-)
> > >
> > > Cheers
> > > - --
> > >
> > > Peter Nixon
> > > http://www.peternixon.net/
> > > PGP Key: http://www.peternixon.net/public.asc
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.2.4 (GNU/Linux)
> > >
> > > iD8DBQFAwadQAcdsUt9pJjwRAu0mAKCmIBEp21Cn7YM8/ahX9g6+oXDccwCg9lsE
> > > SLX/x7KQmWsSk5c/egiQh40=
> > > =KJSf
> > > -----END PGP SIGNATURE-----
> > >
> > > _______________________________________________
> > > Asterisk-Dev mailing list
> > > Asterisk-Dev at lists.digium.com
> > > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > > To UNSUBSCRIBE or update options visit:
> > > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > >
> >
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >
> >
> >
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
More information about the asterisk-dev
mailing list