Top.Mail.Ru Yandeks.Metrika
Forum: "Bases";
Current archive: 2002.01.08;
Download: [xml.tar.bz2];


HELLO! I make a journal. Where did the task .... Find similar branches

@andrew   (2001-12-04 11:38) [0]

... it is necessary to make a check on the uniqueness of the entered date. To the same time did not have two events. Do not tell me how to check this check by the table constructor or the query before the "insert into ....." line? Thank!

Val   (2001-12-04 13:11) [1]

not a check is needed, but a unique index, which will include this date field

@andrew   (2001-12-04 13:58) [2]

And this is how: "which will include the date field"? Does this mean that the "date" field is unique? If it means, then it is not quite good, because in fact, interested in to time intervals events did not overlap. For example one event from 5 to 8 in the morning. The other is from 6 to 7. If you do a check on the uniqueness of the index, then SQL will allow you to make a record, but should not.

@andrew   (2001-12-04 14:05) [3]

In fact, you can come up with several solutions to my problem. The most elementary that is spinning in my head, namely: first return all the values, then sort through them, look ..., etc. - very long and brake. Maybe someone just came across and knows some ready-made solution to my question: fast and simple and yet, preferably, not at the software level, but at the SQL or SQL query level, because in the variant of solving the problem at the software level when a large number of users are working right away, the time delay "select * ...; check .....; if everything is OK-insert something ...." can be fatal.

Thanks again in advance!

Mick   (2001-12-04 14:07) [4]

In general, normal journals are written sequentially. The date is inserted not by the client, but by the server. If a process started in 5 and ended in 8, then the log will contain the 1 start record (5 am), one end record (8 am) and a cloud of records between them that tell you what happened at that time.

Nest   (2001-12-04 14:14) [5]

Yes, yesterday I also had such a question.
But I have postponed his decision so far - there are more important things.
In general, I think your period should be characterized by 2 parameters;
date_start_start and date_time_end.
So, if at any moment in time there can only be a full event, then when entering it is necessary to check that:
[1.date_time_start <date_time_end]
2. There is no record for which the end date_time is empty or greater than the start date_time entered.

Probably these thoughts should be brought to mind - there was no time. For now, only a vague idea.

@andrew   (2001-12-04 14:17) [6]

> Mick
Not really.
This is not a journal in the computer sense of the word, but a journal as an organizer, a diary in which you can write down some plans for the future time.

@andrew   (2001-12-04 14:24) [7]

> Nest
Well, yes, in principle, the idea is clear. But this is a software solution. Those. roughly speaking, before I want to write something down, I do:
1. Return all records, sorting them by date_time.
2. Become the last line (Query1.Last)
3. If the start time of what I want to insert> = the time of the end of the last recording, then you can insert it.
Is it possible the same, only not by software, but by request?

I’m just afraid that if several people work simultaneously, you can screw it up.

Nest   (2001-12-04 14:36) [8]

And what so does not drive?
1.Query1: Select max (DVK)
2.If query1.fields [0] .asdatetime> DVN_Enited then abort

To make and check and insert in one query, it’s necessary, IMHO, to have a nice number of% @ tsya. A pair - easy.

Nest   (2001-12-04 14:38) [9]

Maybe you can - just sit and think about elementary logic, and how to present it in the WHERE query.
I gave the idea - then try to think further. I just have no real time.

Mick   (2001-12-04 14:39) [10]

You can follow the path of denormalizing the log table.
1. Key field (any Primary Key artificial)
3 Fields of hours (by the number of hours per day)

The client checks the continuity of the inserted interval (easily)
The trigger in the table checks whether NOT NULL values ​​are in the fields of the same name in the records for the same date.
If there is, then they caught the overlap of events, if not - everything is fine.

Sam   (2001-12-04 19:27) [11]

What about triggers?

kaif   (2001-12-04 20:17) [12]

A couple of years ago I was solving this exact task to organize an appointment with a doctor. Did at InterBase. The algorithm is completely non-trivial. In order for this to work quickly, of course, we need indices. It was necessary to create gaps, as separate records, the stored procedures for “crushing” gaps and “gluing” were required. At first, “free time gaps” are created, then they are broken up, as they do for some time. Accordingly, their number gradually increases. Specific cases are tied to the surrogate unique index of these intervals. Worked quickly and consistently with the simultaneous access of a number of users. I then thought a lot and tried different options. Without turning individual gaps into objects that would be created, deleted, and used, I found no other good solution.

Pages: 1 whole branch

Forum: "Bases";
Current archive: 2002.01.08;
Download: [xml.tar.bz2];


Memory: 0.59 MB
Time: 0.027 c
2001-12-15 13:55
Prompt component Button

2001-11-08 00:17

2001-12-16 22:22
How to take the root of the nth degree in Delphi?

2001-12-06 15:43
Data Field not permitted on open DataSet

2001-12-05 11:32
about SQL

afrikaans albanian Arabic armenian azerbaijani basque belarusian bulgarian catalan Chinese (Simplified) Chinese (Traditional) croatian Czech danish Dutch English estonian filipino finnish French
galician georgian German greek haitian Creole hebrew Hindi hungarian icelandic indonesian Irish italian Japanese Korean latvian lithuanian macedonian malay maltese norwegian
persian polish portuguese Romanian russian serbian slovak Slovenian Spanish swahili Swedish thai turkish Ukrainian urdu vietnamese welsh yiddish bengali bosnian
cebuano Esperanto gujarati hausa hmong igbo javanese kannada Khmer lao latin maori marathi mongolian nepali punjabi somali tamil telugu yoruba
English French German Italian Portuguese Russian Spanish