When you store date/time AS date/time in database you store some binary (like milliseconds since 1st of January 1970). Database do nothing and care less about the representation of that date/time. You have to look into the code to see where the problem (you may have locals with 12 hours).
If you store date/time as string - you do a big mistake!!!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
There is no datetime format in which the computer system stores a datetime.
Once you understand this you can then understand that the format of the datetime data returned to you will be dependent on the collation of your database, when you perform a simple select,or the format you extract the data as.
All you need to remember is that the datetime value is saved, within the database, as a number and you will then understand that all formatting issues are resolvable.
N.B. for this reason never save a datetime as a string as if you do you will lose precision.
“That which can be asserted without evidence, can be dismissed without evidence.”
1. Single database is the better design, there are strategies to handle large volume. Extreme data (think Google, facebook, Amazon etc) requires a different strategy but it is probably too early to begin taking that into account.
2. Much more than a startup site can expect to see.
3. See 1 - same question
4. Don't create multiple databases - removes the question.
5. Performance like Amazon is above and beyond your short/medium term expectations, I imagine they have a large dedicated team simply looking after their database systems. Any of the hosting companies will be delighted to meet you short/medium term needs.
If your database is designed properly it will be scalable, I would suggest getting a professional to design your system. An excellent specification will facilitate the design.
Never underestimate the power of human stupidity
Hi can anyone help me I don't necessarily want a solution just an idea.
I have a table e.g
ID - Start Date - End Date - Difference(Duration) - SessTotal - SessID
Now the Id is per user. and the date difference is the time spent doing something. If the difference is greater than 30 minutes I need to increment the session ID by 1.
Second I need to create a running total for session total per session.
1 session ID must also not be able to have more than 1 UserID [ID] in it's row.
I absolutely have to display the date difference that is how the specification is made.
Let me try saying it this way:
I have to have a running total for the times until there is a 30 minute or larger gap or if a new user ID which is a different person is the next row of the dataset. then that is a session then I have to increment the session ID for each Session.
SET [Session ID] = [Session ID] + 1
WHERE [Date difference] < 30 Minutes
OR If dates run out for this person presenting a new person.
And for then the running total must start again. It is allot to ask I am sorry but any help would be greatly appreciated.
Thank you for the function, but it is not quite solving my problem. If you could maybe give me a guideline on how I can update using this row combined with the following row. and then also group by as to not overlap users? if not then thank you for your effort.
Thank you that helps. I do understand when you guys say calculated fields should not be stored but I have to store summary's of 80 million rows. and when they are stored they will not change but get added to. I could show you my query then you could tell me what to improve if you want. but thank you any way
Interesting I will go take a peek at OLAP, The only problem is I am moulding the data in parts updating parts after the initial insert. I just need to get a running total of the date difference (Which is used as time) and I need to restart the counting when the difference (not the total) is more than 30 minutes and then I need to assign that session an ID a session ID must not lap over different users. the part I am stuck with is 1. the running total of the time difference 2. assigning incremented ID's based on this logic
[Edit]: Your left join idea helped already thank you
Last Visit: 31-Dec-99 19:00 Last Update: 9-Dec-23 8:00