On 08/11/2013 18:08, James Laver wrote:
On Fri, Nov 8, 2013 at 5:22 PM, Yitzchak Scott-Thoennes
wrote:
On Fri, Nov 8, 2013 at 12:38 AM, Mark Stringer wrote:
I'd guess that the date_created is being stored in the table, so could be
used to order the records without the need for a serial, if or
On Fri, Nov 8, 2013 at 5:22 PM, Yitzchak Scott-Thoennes
wrote:
> On Fri, Nov 8, 2013 at 12:38 AM, Mark Stringer wrote:
>> I'd guess that the date_created is being stored in the table, so could be
>> used to order the records without the need for a serial, if ordering is the
>> only concern.
>
> N
On Fri, Nov 08, 2013 at 05:11:14PM +, Peter Sergeant wrote:
> On Fri, Nov 8, 2013 at 3:02 PM, Abigail wrote:
>
> > I opted for two columns, "additional" and "percentage", the first
> > defaulting to 0, the other to 1. Prices can then be easily calculated
> > as original_price * percentage + a
On Fri, Nov 8, 2013 at 12:38 AM, Mark Stringer wrote:
> I'd guess that the date_created is being stored in the table, so could be
> used to order the records without the need for a serial, if ordering is the
> only concern.
Never use date/times as unique identifiers/sort keys.
On Fri, Nov 8, 2013 at 3:02 PM, Abigail wrote:
> I opted for two columns, "additional" and "percentage", the first
> defaulting to 0, the other to 1. Prices can then be easily calculated
> as original_price * percentage + additional. No conditionals needed.
> And the calculation is currency agnos
Abigail writes:
> On Fri, Nov 08, 2013 at 11:43:08AM +, Smylers wrote:
>
> > A discount can either be a percentage or a value in euros. I can
> > think of several suboptimal ways of representing this:
>
> I opted for two columns, "additional" and "percentage", the first
> defaulting to 0, th
On Fri, Nov 08, 2013 at 11:43:08AM +, Smylers wrote:
> I wrote:
>
> > Hello. I'm designing a database schema, and am interested in any
> > wisdom folk can share over a few aspects of it:
>
> Thanks for all the advice so far. One more question I forgot to ask in
> the initial mail:
>
> A disc
Dirk Koopman writes:
> It all depends on the application and your view as to where the
> business might go in the future.
Database design should only be performed by a qualified soothsayer?
James Laver writes:
> On Fri, Nov 8, 2013 at 11:43 AM, Smylers wrote:
>
> > • Separate fields for disco
Abigail writes:
> On Thu, Nov 07, 2013 at 01:03:00PM +, Smylers wrote:
>
> > version should start at 1 for each document and be
>
> I've used triggers to enforce business rules like this in the past
Mark Stringer writes:
> I've used BEFORE INSERT triggers to select the max existing versi
On 08/11/13 11:43, Smylers wrote:
• Have separate euro_discount and percentage_discount tables, then when
a discount applies create a record in the appropriate table. This
avoids any NULLs in the DB (something I've seen advocated as good
database design), but it still requires ensuring t
On 08/11/13 12:29, Nicholas Clark wrote:
On Fri, Nov 08, 2013 at 12:04:06PM +, Ben Smith-Sport wrote:
I seem to have ended up on the above email list by mistake.
I’d be very grateful if you could remove me from it.
All the best
It would have been a confirmed-opt-in mistake :-)
I've unsub
On Fri, Nov 08, 2013 at 12:04:06PM +, Ben Smith-Sport wrote:
> I seem to have ended up on the above email list by mistake.
> I’d be very grateful if you could remove me from it.
> All the best
It would have been a confirmed-opt-in mistake :-)
I've unsubscribed your e-mail address.
For future
I seem to have ended up on the above email list by mistake.
I’d be very grateful if you could remove me from it.
All the best
Ben
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal
views which are not the views of the BB
On 8. 11. 2013 10:06, Smylers wrote:
James Laver writes:
Smylers wrote:
William Blunn writes:
Instead of storing a version ID (e.g. 1, 2, 3, 4, 5, 6), you could
store a SERIAL.
So for one document ID, you might store versions 10, 11, 12, 50,
75, 87.
This was my immediate thought as we
On Fri, Nov 8, 2013 at 11:43 AM, Smylers wrote:
>
> • Separate fields for discount_percentage and discount_amount. This has
> the disadvantage of needing to ensure that a record doesn't have both
> fields set.
>
> If the business concocts another discount type in future, this will
> requir
I must say I quite like playing with triggers. A well encapsulated trigger
shouldn't take too much developer time, and so long as people read the schema
definitions, and the trigger is correctly documented/linked to in the right
places (which may be tricky to anticipate in advance, where the r
I wrote:
> Hello. I'm designing a database schema, and am interested in any
> wisdom folk can share over a few aspects of it:
Thanks for all the advice so far. One more question I forgot to ask in
the initial mail:
A discount can either be a percentage or a value in euros. I can think
of several
On Fri, Nov 8, 2013 at 10:06 AM, Smylers wrote:
> James Laver writes:
>
>> This was my immediate thought as well, but I'd probably cheat and
>> declarr the document version numbers to be oureky decorative
> ^^
> “purely”, I presume?
Yes. Phone keyb
James Laver writes:
> Smylers wrote:
>
> > William Blunn writes:
> >
> > > Instead of storing a version ID (e.g. 1, 2, 3, 4, 5, 6), you could
> > > store a SERIAL.
> > >
> > > So for one document ID, you might store versions 10, 11, 12, 50,
> > > 75, 87.
>
> This was my immediate thought as we
On 08/11/2013, at 19:38, Mark Stringer wrote:
> On 11/08/2013 08:17 AM, James Laver wrote:
>>
>> Smylers wrote:
>>> William Blunn writes:
>>>
Instead of storing a version ID (e.g. 1, 2, 3, 4, 5, 6), you could
store a SERIAL.
So for one document ID, you might store versions
Mark Stringer wrote:
>>
> From the OP: "But version should start at 1 for each document and be
>consecutive."
I'll grant that I've assumed that was to be more friendly to the end user, but
in that case, it really is just cunning use of the .. operator.
>I'd guess that the date_created is bei
On 11/08/2013 08:17 AM, James Laver wrote:
Smylers wrote:
William Blunn writes:
Instead of storing a version ID (e.g. 1, 2, 3, 4, 5, 6), you could
store a SERIAL.
So for one document ID, you might store versions 10, 11, 12, 50, 75,
87.
This was my immediate thought as well, but I'd probab
Smylers wrote:
>William Blunn writes:
>
>>
>> Instead of storing a version ID (e.g. 1, 2, 3, 4, 5, 6), you could
>> store a SERIAL.
>>
>> So for one document ID, you might store versions 10, 11, 12, 50, 75,
>87.
This was my immediate thought as well, but I'd probably cheat and declarr the
do
23 matches
Mail list logo
