SQL Anywhere database replication - SQL Remote or MobilLink?

Author

SQL Remote or MobilLink?

David Kerber

2005-11-08, 9:24 am

We have an existing customer who wants something new from us, and I'm
not sure which way to go with this (I'm a newbie to
replication/synchronization).

We are collecting realtime data from a bunch of sites (gas stations)
over the internet, into a database in our office. The corporate office
now wants us to send that data back to them (nearly) continuously, in a
format which is defined by a view, not the format of the base tables.

Right now, we are batching up the data periodically and ftp'ing it.
When it goes into production, this data will run to many tens of
thousands of individual records per day across 3 different views,
totaling a few tens of megabytes (50 or so, based on the small number of
trial sites). Ignoring bandwidth issues, on which I have a much better
handle, is this a job for MobilLink or SQL Remote? I'm not sure what
they are using for their database server, but believe it's M$ SQL
Server.

If I understand the products correctly, I believe this is best done with
MobilLink but am not sure.

--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

Breck Carter [TeamSybase]

2005-11-08, 9:24 am

The MSS aspect restricts a *straightforward* SQL Anywhere solution to
using MobiLink rather than SQL Remote, and it places your SQL Anywhere
database as the remote and the MSS database as the consolidated. Using
your database as the remote means the upload stream to MSS will be
built from the transaction log, and *that* means base tables, not
views.

However, if each view is simply based on a single base table, and it
has a simple WHERE clause, you could represent the same thing in the
CREATE PUBLICATION for the MobiLink synchronization.

Breck

On 7 Nov 2005 14:30:24 -0700, David Kerber
< ns_dkerber@ns_wraenv
iro.com> wrote:

>We have an existing customer who wants something new from us, and I'm
>not sure which way to go with this (I'm a newbie to
>replication/synchronization).
>
>We are collecting realtime data from a bunch of sites (gas stations)
>over the internet, into a database in our office. The corporate office
>now wants us to send that data back to them (nearly) continuously, in a
>format which is defined by a view, not the format of the base tables.
>
>Right now, we are batching up the data periodically and ftp'ing it.
>When it goes into production, this data will run to many tens of
>thousands of individual records per day across 3 different views,
>totaling a few tens of megabytes (50 or so, based on the small number of
>trial sites). Ignoring bandwidth issues, on which I have a much better
>handle, is this a job for MobilLink or SQL Remote? I'm not sure what
>they are using for their database server, but believe it's M$ SQL
>Server.
>
>If I understand the products correctly, I believe this is best done with
>MobilLink but am not sure.

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com

David Kerber

2005-11-08, 9:24 am

In article < vb51n1tj2u4elukctamv
tuoap3tir6eapg@4ax.com>,
NOSPAM__bcarter@risi
ngroad.com says...
> The MSS aspect restricts a *straightforward* SQL Anywhere solution to
> using MobiLink rather than SQL Remote, and it places your SQL Anywhere
> database as the remote and the MSS database as the consolidated. Using
> your database as the remote means the upload stream to MSS will be
> built from the transaction log, and *that* means base tables, not
> views.
>
> However, if each view is simply based on a single base table, and it
> has a simple WHERE clause, you could represent the same thing in the
> CREATE PUBLICATION for the MobiLink synchronization.

Thanks, Breck -

The views aren't very complex, but they do grab some ID (site name, tank
ID) information from other tables. If worse comes to worst, I guess I
could build tables with the structure of the views and replicate that,
but that solution would essentially double the number of writes to the
database and double the storage requirements. The storage needs aren't
really a problem, but doubling the number of writes wouldn't be too
good.

The other option would be to change how I write the data to the data in
the first place, storing the data in its final format right from the
beginning, though I'd rather not do that unless I have to. Even so,
it's probably a better solution than writing the data twice (like
above). The raw data will not be kept long-term; 30 days at the most
before purging, and probably much less than that.

Of course, I've got to be sure of what they are using for a database
before I make any final decisions.

>
> Breck
>
> On 7 Nov 2005 14:30:24 -0700, David Kerber
> < ns_dkerber@ns_wraenv
iro.com> wrote:
>
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com
>

--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

Sponsored Links