Thanks for everyone's feedback. I think it's time to just give it a
whirl and see what happens.
@Joshua:
"With my personal experience I would go with an ETL and copy the
desired data
directly into your ordering system."
I think that's the approach I'm going to take.
@David:
Thanks for the li
On Mon, Sep 28, 2009 at 6:36 PM, David Larlet wrote:
>
> Le 22 sept. 2009 à 03:10, snfctech a écrit :
> > I understand that there is a Django branch being actively worked on
> > for connections to multiple DB vendors, or that Django + Elixir may be
> > a good option. But I'm wondering if building
Le 22 sept. 2009 à 03:10, snfctech a écrit :
> I understand that there is a Django branch being actively worked on
> for connections to multiple DB vendors, or that Django + Elixir may be
> a good option. But I'm wondering if building a single data warehouse
> may still be a better way to go?
S
I've never used Elixir so I can't really comment on the pros and cons.
With my personal experience I would go with an ETL and copy the desired data
directly into your ordering system. Just keep in mind that these new tables
should stay read-only as far as the ordering system goes. The data would be
"If you need to link one order item to other data in the warehouse it
should
only either be done in the warehouse or between the systems outside of
the
warehouse."
Now we're back to the crux of the topic! Joins in the warehouse, or
cross-vendor joins between disparate systems?
If multi-db _were
No one is recommending multi-db because it's not done yet.
I'm not sure I understand exactly what you mean by "creating new order and
order_item data with keys to data in the warehouse" but that doesn't sound
like a recommended approach.
A data warehouse (in my opinion) should be read only and no
Well, I guess the answer to the thread is looking like:
- a data warehouse is preferable to multiple db connections and cross-
vendor joins
But that's only because I haven't heard anyone voice support for the
multi-db idea.
Now the question is:
How should the warehouse be constructed in tandem
If he wants to discuss it here I can do that too. It was just a little off
topic, but not not too much I suppose.
On Thu, Sep 24, 2009 at 7:41 AM, nausikaa wrote:
>
>
> Hi Joshua
>
> Thanks for sharing your knowledge.
> Too bad, I would've liked to read your suggestion to Tony as well. ; )
> I'm
Hi Joshua
Thanks for sharing your knowledge.
Too bad, I would've liked to read your suggestion to Tony as well. ; )
I'm a just graduate and at work I'm working on something very similar
to what has been discussed here.
On Sep 23, 9:51 pm, Joshua Russo wrote:
> I have many years of database des
I have many years of database design experience and it sounds like you are
getting lost in terminology.
I would start out with a set of tables in the warehouse that mirror the
existing data. In these tables you can either wipe and reload each time, or
create a mechanism to track each individual loa
Thanks for your reply, Joshua.
Complexity is exactly what I'm trying to avoid - but after doing a
little research on data warehouses (I've never built one), that seems
like a very complex route as well!
I would like to just come up with my "dream schema" and run update
scripts on a daily or even
The multi-db branch is just now in the process of being baked into the core
and from what I can tell it's not quite done yet. Even when it is completely
done I would recommend the data warehouse approach. I view the multi-db
functionality more as a last resort, where you really don't have an option
Hi, Nausikaa. Thanks for your reply.
Unfortunately, the legacy systems must remain in place until they are
gradually (if ever) phased out. There's a whole bunch of
functionality that I don't want to have to recreate in those systems
(POS, inventory/accounting, products, etc.). I just want to b
Hi snfctech
With warehouse I assume you mean keeping the datasources and periodic
transfer into a central db (the warehouse).
Why not migrate all your datasources into e.g. a PostgreDQL db?
It is easy to write forms and implement logins/access rights in
django so that your non-technical users c
I understand that there is a Django branch being actively worked on
for connections to multiple DB vendors, or that Django + Elixir may be
a good option. But I'm wondering if building a single data warehouse
may still be a better way to go?
Here's an example of some of the relations I'm going to
15 matches
Mail list logo
