|
True Random number generation is an art - most computer generated random numbers are actually periodic and not truly random. But usually "good enough".
See this site for a discussion of a few truly random number techniques.
http://www.random.org/randomness/[^]
They also offer an API to generate true random numbers.
Melting Away
www.deals-house.com
www.innovative--concepts.com
|
|
|
|
|
If you're assigning a random number to every entry in the table (i.e. every single time you add an entry you associate a random number with it) then a good mechanism to use is the LFSR - Linear Feedback Shift Register.
An n-bit LFSR will iterate through 2^n numbers in a fixed (deterministic) sequence (thus, not very random, but it might suit your purposes for uniqueness) and guarantees to loop back to the first number outputted after 2^n iterations. I'm a little rusty on the details, but it should definitely guarantee that you don't exhaust every number for a "long" time.
Xilinx has a good app note on this: http://www.xilinx.com/support/documentation/application_notes/xapp052.pdf[^]
|
|
|
|
|
Assuming you don't want to use a GUID...
Create a table of number ranges; call it RandRanges. These are the numbers that are not yet taken. Generate a random integer (use the Rand function along with some multiplication and addition) between 1 and the number of items in RandRanges. Use that number to select a row from RandRanges. Use the min/max values (i.e., the range) as the min/max of a random integer you will generate. Once you generate that integer, use that number as your desired random number. Then, modify the RandRanges table to take that value out. You can do that by deleting the row you just created and splitting it into two new ranges that you insert into the table.
For example, say RandRanges starts out with:
1: 1-100
2: 101-200
You then generate the random number 2, so you are gonna use the second item in RandRanges.
101-200
Now, you generate a random number between 101 and 200. Say that turns out to be 150. You would take that out of RandRanges:
1:1-100
2:101-149
3:151-200
You then use your unique random number, 150, however you like. This table will grow at about the same rate that you use the unique random numbers, so you don't have to worry too much about space considerations. In fact, the table will sometimes shrink. If you use up all the random numbers (not likely with an Int64 range), the table would become empty.
|
|
|
|
|
Perhaps try to redefine the problem a bit. For example, if it's an activation code then you can make it out of two parts: one sequential part, and a random part. If the sequential part is unique, the activation code will be unique. Of course the drawback is that you can issue less activation codes but I do not imagine that you want to activate 2^64 whatevers 
|
|
|
|
|
Uh, I think you meant to post that as a reply to the OP's message and not as a reply to mine.
|
|
|
|
|
I want to know how can I list all database in mysql? and also how to show all tables within the selected database?
|
|
|
|
|
You can't (as far as I know).
List tables (if I recall correctly).
Edit: It's show tables and also describe <table>
|
|
|
|
|
Having limited (none) experience with mysql I can only recommend that you look into the system table, sql server has a master database that stores the db information, I'm pretty sure mysql will have something similar.
There should be system tables that hold the meta data for the database somewhere in mysql, research will be required. There are lots of responses from Google for this enquiry.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
jrahma wrote: I want to know how can I list all database in mysql?
By keeping track if the tables you make. Create a tabled called "MyTables", and add an entry whenever you successfully issue a CREATE command
I are Troll 
|
|
|
|
|
Im using the object DataContext to save some object to DB. I see that the object presistence is Ok - but after i stop the debug and i recompile it - i dont see the object anymore.
The saving action that i did:
dataContext.table.InsertOnSubmit( someObject);
dataContext.SubmitChanges();
modified on Sunday, December 5, 2010 7:56 AM
|
|
|
|
|
If they've been persisted, query them back.
|
|
|
|
|
I impliment the InsertCustomer method - the code :
<br />
void InsertCustomer(Customer instance)<br />
{<br />
this.ExecuteDynamicInsert( instance ); <br />
}<br />
And still nothing saved in the DB file.
|
|
|
|
|
That's not what you said in the original post.
|
|
|
|
|
|
Sorry ... i did not said that dataContext is define in the code below
public partial class dataContext : System.Data.Linq.DataContext
{
....
}
|
|
|
|
|
Yes, of course you are subclassing DataContext. I understood that. Would like to answer the question now?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I dont know the other way.
I saw in all the code example that i need create subclassing Datacontext and with this subclassing to call the InsertAllOnSubmit and SubmitChanges method.
Please tell me where i wrong.
|
|
|
|
|
And therein lies the problem, trying copy and paste code you don't understand.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
We have a couple of instances where this has come up in the past and now dealing with another and thought it'd be good to get input on what everyone's best recommendation and real-world experience has been with the following scenario:
1. Consider a situation where you have a single database entity that you want to relate to many other database entities.
2. For example, a table called "CommunicationLog", which is intended to store details (comments, user, date/time, etc.) related to communication with a Customer
3. However, in addition to storing the communication details in relation to the Customer, we also want to relate these records to other entities. For example, we want to identify if this communication is related to a specific Product, a Work Order, a Sales Order, a Quote, a Contract, another Employee, etc.
4. The entity we're referring to in #1 is intended to be very generic so we want it to be in one table rather than having a table for each of the entities in #3 (eg. SalesOrderCommunicationLog, WorkOrderCommunicationLog, etc). Why do we want this in one table?
4a. Maintainability - we see no reason to create multiple tables that are doing the same thing, when the only thing that differentiates each record is what the record relates to.
4b. By allowing a communication log record to be related to multiple entities it's more powerful - we're able to identify a customer complaint, for example, not only by customer, but also with a specific work order, product, etc.
4c. Having all these details in one table makes it easier to search and cross-reference comments that may be related to multiple specific identities
So hopefully that explains what we're trying to accomplish. My question is, what is the best way of implementing this, based not only on proper database form, but also considering real-world scenarios.
Here are the two approaches we've been looking at (but if you have another idea I'd be interested to hear):
Approach 1. Add a field for each new entity that this record relates to - this ensures good database integrity, but it also means that tables, relationships, stored procedures and other code need to be added/altered every time we decide that we want the Communication Log record to relate to another entity AND it results in a table with 10+ fields, of which many may be left null for a lot of the records.
Approach 2. Create a "CommunicationLogRelated" table with fields for CommunicationLogID, RelationType, and RelationID. RelationType would be used to identify the other entity that this CommunicationLog record is related to and RelationID is used to identify the PK of the other entity. The clear advantage to this is a "cleaner" table design and much easier to add new related entities. However, we lose referential integrity. I'm also not sure if there's a performance benefit to one approach vs. the other.
I've looked for patterns, but have not had any success in finding a pattern that mimics the above scenario. I'd really appreciate feedback on this, especially if you've implemented something like it in the past.
Cheers,
Chris
|
|
|
|
|
I don't know the best solution for your cases, but what I do is formally write down all of the potential entities (tables) and their attributes (columns). Once you have that, then start looking at normalizing the database. That usually makes it fairly obvious what needs to be in tables and what needs to be indexed.
And if that happens to coincide with someone's idea of a pattern, great. If not, so be it.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I always go with approach 2, this leaves you with an extensible design which IMHO out weighs most other considerations. Yes you lose the ability to place FKs on the table (to your type) but I consider that a small price to pay for either adding columns or worse adding tables every time the client thinks up a new type.
I recently offered to castrate a junior dev who was insisting on approach 1 just to have the FKs so his diagram and therefore reports would be easier.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I'll agree with you on this one.
|
|
|
|
|
Thanks for the input. I tend to be one of those people that will go with DB ref integrity when possible, because (in my experience) it's the best way of ensuring that true integrity exists - when there are too many devs on one project it just takes one lazy Friday afternoon for somethign to slip by. Yes, it can be caught in unit/qa/whatever, but controlling it at the DB is a great insurance policy.
On the other hand, we rarely, if ever, actually allow record deletion. And the second approach is definitely more flexible.
Thanks
|
|
|
|
|
Yeah, number two beats number one.
But what about taking it a step further and allowing for many-to-many association of notes to entities? Unless you invoke YAGNI, I could see the conceptual benefit of allowing multiple notes for an entity and associating one note with multiple entities. If you like, you could have a notes table for each table for which you want to associate notes; that would reduce the amount of table duplication. I wouldn't be concerned about the lack of referential integrity*; you could implement that programatically, or even have a cleanup routine to delete orphaned notes.
Another alternative is to have a notes field in each table that should support notes. That allows referential integrity, but only one note per entity -- unless you chain notes together.
* I've said it before and I'll say it again... I once worked at a place where referential integrity wasn't allowed in production databases -- once the applications were tested, it wasn't needed and it "bogged down the database"**. 
** Rdb on OpenVMS.
|
|
|
|
|
Hi - thanks for the input.
Truthfully our design already allows for a many-to-many - I just didn't include that detail here because I was trying to keep the explanation less "muddy". Our intent is to allow one or many notes to relate to one or many (and any combination of) customers, quotes, work orders, products, etc. The potential power of knowledge-base access based on this approach is great - the real question is going to be creating a UI that encourages the users to easily select the related criteria and/or BL that automatically selects the appropriate matching related items.
For ref integrity, one thing I forgot to mention is that we rarely ever allow record deletion through most of our objects so it should be even easier to control that programmatically.
I'd prefer to steer away from the one Notes field per table - that limits us to a very 80's approach and hardly moves us forward.
I admittedly do not invoke YAGNI enough, but in this case our immediate need for multiple fields already justifies the above approach; knowing that this will likely be expanded just adds yet another argument to the approach.
As for the approach of ref integrity not being allowed in production dbs... well I've personally seen the mess that can create. While that mess may certainly be related to holes in another processes (dev, testing, qa, etc.) I still don't expect to ever implement that type of policy. It's one thing to have orphaned records in a communication log, quite another to have an orphaned inventory audit trail!
Thanks so much for the reply.
Cheers,
Chris
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
