|
I'm building an retail appliction where the software will be installed locally on the client. There will be a local copy of the database, and the software will do CRUD operations on it.
Then, each day the software will send inserts/updates/deletes to the server. On the server the database is identical to the local DB.
The reason for this design is that if the user cannot connect to the server, the software has to still be able to run. The customer cannot be stopped from using the software in their store because they cannot connect to the server.
To facilitate this I'm going to use composite primary keys. The first part of the key is the CustomerId, and the second is the Id of that table. So, for an Order row the key would be CustomerId + OrderId. This way, when the data is pushed to the server I will have unique keys across all customers.
The question is this... Assume a new customer downloads and installs the software. How do I get the CustomerId? I'm guessing that during setup I would connect to the server and get the next available CustomerId, and to do that I would have to store the CustomerId to the server's table right then & there. But again, what if they can't connect?
Anyone have a better idea? Any problems with this design?
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
Why not use a GUID for the id field? It's better because it doesn't rely on knowledge of server values.
|
|
|
|
|
I thought of that, but then I figured I didn't want to be transmitting alot of GUID's to the server. Seems like alot of data each trip.
If it's not broken, fix it until it is
|
|
|
|
|
As much as I loath the blind use of Guids, they don't consume "that much". And no, you needn't select the Guid with each record that you're fetching, it'd only become part of the filter-statement.
Bastard Programmer from Hell 
|
|
|
|
|
Kevin Marois wrote: , but then I figured I didn't want to be transmitting alot of GUID's to the server.
However each guid represents a row and the row will have data. That is more significant.
And what do you think a "lot" is exactly?
|
|
|
|
|
Kevin Marois wrote: But again, what if they can't connect?
Have them call you, you select the next identity from the server, and have them enter it. There's really no alternative to a non-existing connection.
Bastard Programmer from Hell
|
|
|
|
|
One way to deal with IDs in disconnected systems is to have the server pre-allocate a number of them and distribute them in advance to the clients (give each of them a chunk); the clients would then hold "empty records" they can fill up at their own pace.
BTW: Whatever your solution will be, you must consider that a customer could interact with more than one retail point, so sooner or later you may need a way to coalesce some records.
|
|
|
|
|
Bloody hell, we built this system in the 90s and it was a PITA then! We used GUIDs and if they cannot connect they cannot download - have them register when they download - if they do not install then delete them at some later time. There is nothing wrong with the ID/ID structure it is just more work to maintain and you are saddled with a composite primary key.
This is where I got my loathing of GUIDs they really are irritating to debug with. We also segregated the data so the user only replicated their own information locally, not the entire database!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I got to thinking about my design some more....
My application will be installed in a retail environment. My initial design calls for the software to work even if there's a loss of internet connection. So I thought of installing a local copy of SQL for my app to work with. Each night the app's update service would then transmit any data to the server that's not already been sent.
But then I got to thinking, it's possible for there to be multiple PC's in any given store. What if there's no network? I could offer to install a basic peer to peer network, and make the first PC the server, then all the other PC's could hit the DB there.
I went into this thinking thatI can't assume an internet connection. Do you think this is unreasonable in today's world? Should I build the app so that all data resides in the server and require them to have an internet connection? It would solve both the internet and network the issues.
Your thoughts?
Any thoughts on this?
If it's not broken, fix it until it is
|
|
|
|
|
It depends on your market, small outlets I would think. However even small outlets often have multiple POS. A large, multi shop company will require the data to be consolidated but the POS operation is decidedly local.
I would build a local environment (WPF on the desktop) and make sure you cater for a replication scenario where the local server can replicate its data to HO. Personally I see absolutely no requirement for the internet in such an environment.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Ya, it's a tough design decision. I'll sleep on it over the weekend.
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
hi, my question is
if i have 3 basic colors (each made of rgb):
color1 : R:150, B:zero, G:255
color2 : R:255, B:150, G:zero
color3 : R:zero, B:255, G:150
each of them can be mixed using the formula :
new_color = floor(X*0.9)+floor(Y*0.1)
X and Y can be abasic color or a new color allready created by using the formula.
for example, if i want to mix color1 as main with color3 :
new_color(R,B,G) = (floor(0.9*150)+floor(0.1*0) , floor(0.9*0)+floor(0.1*255) , floor(0.9*255)+floor(0.1*150) ) = (135, 25, 244).
<b>I need to find a way to mix the colors in order to get a desired color, for example : R:187 B:135 G:201.</b>
so far i wrote a "brute force" program which go all over the combinations of basic colors (runing for 7 days now...)
hope there is a smarter way to solve the problem.
Thanks.
|
|
|
|
|
That's called linear equations.
150a+255b+0c=187
0a+150b+255c=135
255a+0b+150c=201
|
|
|
|
|
by solving this equation i get an answer :
X = 0.6077
Y = 0.3759
Z = 0.307
That give me nothing...
Im talking about mixing many basic colors in order to get one special, i need to find the mixing sequence.
|
|
|
|
|
At that point, the problem is half-solved. Next step would be to find how to get there...
One way, would be to mix Y and Z (and any resulting color) until you get the proper ratio by using the best 2 candidate colors that consist of Y and Z or their mix.
Once you have done that, you repeat same process with that mix and X.
The ratio for Y and Z alone would be 0.55 and 0.45.
1) 0.9Y + 0.1Z --> Mix 1
2) 0.9 M1 + 0.1Z --> Mix 2 --> 0.81Y + 0.19Z
3) 0.9 M2 + 0.1Z --> Mix 3 --> 0.72Y + 0.28Z
...
6) --> 0.53Y + 0.47Z
At that point, you would take 0.9 of that and 0.1 of Mix 3... and you get 0.549 of Y.
If you need more precision, you can do more mix...
Philippe Mori
|
|
|
|
|
Since you know the final RGB values that you need, what is the purpose of mixing other colours? Your question needs some clarification.
|
|
|
|
|
first forgive my poor english, hope i can explain better now.
It is a riddle spread out at my university.
you have 3 basic colors (no other colors are available besides the basic colors and the ones produced by mixing the basic colors)
and a machine which can mix them according to the formula i wrote.
the target color is created by mixing the basic colors or their products in the machine.
some colors take up to 1000 mixing steps so the way i try to "solve" it can take forever.
i dont know much about solving such problems so i ask for help here.
thanks.
|
|
|
|
|
Kobi_Z wrote: It is a riddle spread out at my university.
That makes it clear. However, this being primarily a technical programming forum, I'm not sure if you have come to the right place.
|
|
|
|
|
any suggestions where i can ask ?
on math forum i was told to go to programmers forum...
thanks.
|
|
|
|
|
|
This[^] might help.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
These questions are more about validating how I create apps. I know how I like to do things, but I'm curious how the rest of you do it, so feel free to critique or post suggestions.
I created a playground WPF app for tracking projects. The purpose of this app is primarily to play around and learn. In it I have UI, Entities, DAL, and BL projects. In the DB I created Company, Client, and Project tables. The Projects table has FK's for 3 lookup tables. See the pic here[^]
My project entity looks like this
public class ProjectEntity : _EntityBase
{
public int ClientId { get; set; }
public int ProjectTypeId { get; set; }
public int ProjectStatusId { get; set; }
public int PayTypeId { get; set; }
public string ProjectName { get; set; }
public DateTime? EstStartDate { get; set; }
public DateTime? ActualStartDate { get; set; }
public DateTime? EstEndDate { get; set; }
public DateTime? ActualEndDate { get; set; }
public bool? IsActive { get; set; }
public decimal PayRate { get; set; }
}
Ok, now for the questions:
1) Would you have your entity objects maintain references to other entities, or just the PK? For example,
in the ProjectEntity I have ProjectTypeId which stores a reference to the Project Type row in lkpProjectTypes.
When I get a project entity, should I create and store a ProjectType entity on it, or just the PK?
What I usually do is store the PK of the lookup table, then call a method in the DL to get the lookup entity when
it's needed. But I could make the GetProject method in the DL create related object when its called. The
problem is that now you have a heavy object when you may not always need the child objects.
2) Similar to #1. When you create an instance of the ProjectEntity, would you create a ClientEntity and store it
on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store
on the ClientEntity which is stored on the ProjectEntity? Conversely, if you create a ClientEntity, do you store
a list of ProjectEntities on always? If all I want is to display the Client's name, then getting a fully loaded
ClientEntity seems like overkill.
3) How do you handle nulls, both in the DB and in the app? I'v heard some folks say never store nulls. I don't agree
with that, but I'd like to hear your thoughts.
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: 1) Would you have your entity objects maintain references to other entities, or just the PK? For example,
in the ProjectEntity I have ProjectTypeId which stores a reference to the Project Type row in lkpProjectTypes.
When I get a project entity, should I create and store a ProjectType entity on it, or just the PK?
I'm passing the integers around that represent the PK; a list of integers is simple, has little overhead and makes debugging easy. It's also not a large amount of "work" to fetch an ActiveRecord object based on it's handle.
Kevin Marois wrote: 2) Similar to #1. When you create an instance of the ProjectEntity, would you create a ClientEntity and store it on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store on the ClientEntity which is stored on the ProjectEntity? Conversely, if you create a ClientEntity, do you store a list of ProjectEntities on always? If all I want is to display the Client's name, then getting a fully loaded ClientEntity seems like overkill.
It would add some complexity to ensure that you don't waste too much resources. I do not see many additional benefits to this approach though.
Kevin Marois wrote: 3) How do you handle nulls, both in the DB and in the app? I'v heard some folks say never store nulls. I don't agree with that, but I'd like to hear your thoughts.
I think people should use arguments to defend their one-liners. It is said that a normalized database does not allow for "empty" values; on the other hand, the database-server provides you with the option. In practice, it's easier (and cleaner) to have a nullable field, than it is to have a new set of facts.
Bastard Programmer from Hell 
|
|
|
|
|
Kevin Marois wrote: Would you have your entity objects maintain references to other entities, or
just the PK?
Depends on the nature of the objects and how they are used in the rest of the code.
Kevin Marois wrote: The
problem is that now you have a heavy object when you may not always need
the child objects.
Yes that is the problem.
First however it must in fact be 'heavy' in terms of the production system.
So 10 rows isn't 'heavy' but one million certainly is. And if a sub entity represents 100 meg of data then even 10 of them is too many. But for the one million case it would always need to do a deferred look up.
For larger ranges with more moderately sized (much smaller sub entities) it depends on actual data and how it will be used.
Kevin Marois wrote: When you create an instance of the ProjectEntity, would you create a
ClientEntity and store it
on the ProjectEntity instance? If so, do you then
go up the logical tree and create a CompanyEntity to store
on the
ClientEntity which is stored on the ProjectEntity?
That question doesn't make much sense to me. A 'company' seems likes an owner. You can't create an owned object until you create the owner. And you shouldn't even allow for that possibility. Thus in the GUI the user must select a 'company' before doing anything with a owned object.
Kevin Marois wrote: 3) How do you handle nulls, both in the DB and in the app
I handle them as nulls. Presumably for the "app" you mean in the data object. If you mean system wide then the question is wrong because they way a business object deals with nulls is different than how the GUI deals with them.
|
|
|
|
|
I'm curious what people are using for application security in WPF/Windows apps? I personally don't like the .Net Framework Security. I have rolled my own user/rights tables and associated code.
If it's not broken, fix it until it is
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
