Подсчёт ссылок на строку таблицы в MySQL

← →
asail © (2012-10-04 20:17) [40]

> sniknik © (04.10.12 20:00) [39]

> какие то у тебя странные представления о транзакциях...

С чего бы? Ну, вот пример (изначально "My Gorod" существует):

T1: START TRANSACTION
T2: START TRANSACTION
T1: DELETE FROM GORODA WHERE NAME="My Gorod"
T2: SELECT COUNT(*) FROM GORODA WHERE NAME="My Gorod"
T1: COMMIT
T2: COMMIT

Че вернет SELECT? За исключением DurtyRead типа транзакций (этот тип, кстати, не всеми серверами поддерживается)?

← →
Игорь Шевченко © (2012-10-04 21:16) [41]

> Че вернет SELECT?

COUNT до удаления

← →
Игорь Шевченко © (2012-10-04 21:17) [42]

к посту [41]:

Personal Oracle Database 11g Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

← →
asail © (2012-10-04 22:01) [43]

> Игорь Шевченко © (04.10.12 21:16) [41]

Пральна. Об чем и речь собсна в [38]...
Т.е. город, вроде удалили, но вторая транзакция об этом не знает еще. Соответственно, может и не позаботиться о вставке этого города снова. А первая вполне может удалить город, бо она еще не знает, что вторая будет вставлять новую компанию, к этому городу привязанную... Короче, вполне стандартное поведение клиент-серверных БД.

← →
Игорь Шевченко © (2012-10-04 22:15) [44]

asail © (04.10.12 19:55) [38]

> Но, в том-то и дело, что на момент проверки второй транзакцией,
> а есть ли город, результат будет положительный. Хотя первая
> транзакция, его удаляющая, уже стартовала, но не закоммитилась.
> ..

SQL> create table foo (name varchar2 (30) not null primary key); Table created. SQL> create table bar (name varchar2 (30) not null primary key, foo varchar2(30) not null references foo(name)); Table created. SQL> insert into foo values ("MOW"); 1 row created. SQL> commit; Commit complete. T1: SQL> delete from foo where name = "MOW"; 1 row deleted. T2: SQL> select count(*) from foo where name = "MOW"; COUNT(*) ---------- 1 T2: SQL> insert into bar values ("FOO", "MOW");

Здесь T2 зависает в ожидании результата первой транзакции. Если T1 выдает ROLLBACK, то T2 завершается успешно. Если T1 выдает COMMIT, то T2 завершается с

insert into bar values ("FOO", "MOW")
*
ERROR at line 1:
ORA-02291: integrity constraint (IF.SYS_C0031735) violated - parent key not
found

← →
asail © (2012-10-04 22:45) [45]

> Игорь Шевченко © (04.10.12 22:15) [44]

> Здесь T2 зависает в ожидании результата первой транзакции

Ну, это уже зависит от типа сервера и/или параметров транзакций.
Т.е. надо вешать обработку и разруливание коллизий на клиентах. Понятно, что такие коллизии можно и должно разруливать. Но, лучше их избегать, если есть возможность. Потому, в случае ТС, лучше и не удалять города из справочника. Тогда и заморачиваться на разруливание не придется...

← →
Игорь Шевченко © (2012-10-04 23:41) [46]

asail © (04.10.12 22:45) [45]

> Ну, это уже зависит от типа сервера и/или параметров транзакций.
>

Разве ? Это обеспечение FOREIGN KEY. Нельзя завершить одну транзакцию, если другая имеет неподтверженные изменения, связанные с ограничениями целостности.

Это поведение равносильно одновременной вставке двумя транзакциями одинаковых значений PRIMARY KEY, например. Стартовашая позже транзакция будет ждать результата более ранней.

← →
asail © (2012-10-05 03:22) [47]

> Игорь Шевченко © (04.10.12 23:41) [46]

> Разве ? Это обеспечение FOREIGN KEY. Нельзя завершить одну
> транзакцию, если другая имеет неподтверженные изменения,
> связанные с ограничениями целостности.

Нельзя, конечно. Я другое имел ввиду - что необязательно ожидает. Может и сразу отвалиться вторая транзакция. Например, в интербэйсе есть флаг у транзакции wait/no_wait...

← →
sniknik © (2012-10-05 08:25) [48]

> Например, в интербэйсе есть флаг у транзакции wait/no_wait...
как понимаю, тогда во второй, выполненной в "середине первой", будет либо сразу состояние "до", либо подождав состояние "после" от первой транзакции.
и никаких коллизий, от того, что первая что-то начала менять, а вторая схватила состояние "наполовину измененное" не будет. если бы так было (влезть в середине) то вообще не было бы смысла в транзакциях.

ИМХО, то что ты описываешь это глюк программиста который заранее делает проверки, а меняет по ним после, когда уже нет данных которые проверял... от транзакций такое не зависит.

← →
AV © (2012-10-05 08:44) [49]

> sniknik © (05.10.12 08:25) [48]

Кстати, Николай, а грязное чтение в MSSQL?

← →
Ega23 © (2012-10-05 09:30) [50]

> Кстати, Николай, а грязное чтение в MSSQL?

Read uncommitted, в MSSQL isolation level по-умолчанию.
Есть ли в стандарте (read uncommitted), я, к сожалению, не помню.
Ненаказуемо.
А что с ним не так?

← →
Игорь Шевченко © (2012-10-05 09:50) [51]

asail © (05.10.12 03:22) [47]

> Может и сразу отвалиться вторая транзакция

Не может.

← →
sniknik © (2012-10-05 10:01) [52]

> MSSQL
из справки 2000-го (может в новых расширили, не знаю) все что есть
READ COMMITTED
Specifies that shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

READ UNCOMMITTED
Implements dirty read, or isolation level 0 locking, which means that no shared locks are issued and no exclusive locks are honored. When this option is set, it is possible to read uncommitted or dirty data; values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the four isolation levels.

REPEATABLE READ
Locks are placed on all data that is used in a query, preventing other users from updating the data, but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction. Because concurrency is lower than the default isolation level, use this option only when necessary.

SERIALIZABLE
Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.

← →
AV © (2012-10-05 10:11) [53]

>> MSSQL

Да ничего, с ним не так. Все нормально :)

я это к

> как понимаю, тогда во второй, выполненной в "середине первой",
> будет либо сразу состояние "до", либо подождав состояние
> "после" от первой транзакции.
> и никаких коллизий, от того, что первая что-то начала менять,
> а вторая схватила состояние "наполовину измененное" не
> будет. если бы так было (влезть в середине) то вообще не
> было бы смысла в транзакциях.

т.е. READ UNCOMMITTED позволяет загнать себя в угол. Читая грязные данные.
ну и конечно, ССЗБ, если так читаешь
Но принципиальная возможность все же есть.

Хотя..
Как мы тут спорили как-то, она, а принципе, и не нужна.
Незачем читать неподтвержденное..

← →
Ega23 © (2012-10-05 10:33) [54]

> Как мы тут спорили как-то, она, а принципе, и не нужна.

Когда-то давно лет 6 назад по пьяной лавочке изголялись на спор над какой-то там фигнёй. Обстоятельств не помню, но почему-то в голове крутится именно read uncommitted и dynamic cursor.

← →
Ega23 © (2012-10-05 17:32) [55]

По сабжу: тут вот выходил курить и подумалось. Вот есть город "Александров" (Владимирская обл.). И есть хутор Александров (Морозовский район Ростовской обл.).
Про всякие "Красные Октябри" или "Советские" я вообще молчу.
Как такое разруливать?

← →
sniknik © (2012-10-05 18:32) [56]

> Как такое разруливать?
по кладру например.
у всего есть код, и когда выбираешь например "москва" то делаешь по вводимому поиск, и предлагаешь список на выбор г. москва, д. москва тамбовской области, пос. москва и т.д. 17 вариантов, в базу пишешь его код, по которому все можно определить.

← →
asail © (2012-10-05 18:52) [57]

> Игорь Шевченко © (05.10.12 09:50) [51]

> Не может.

В интербэйсе может. За ораклы не скажу...

> Ega23 © (05.10.12 17:32) [55]

> Как такое разруливать?

Надо в БД географические координаты хранить. Потом уже по ним подставлять соответствующий город из справочника. :)

← →
Inovet © (2012-10-05 19:49) [58]

> [55] Ega23 © (05.10.12 17:32)
> Как такое разруливать?

Последовательно: регион, район и/или город, населённый пункт если надо, улица, дом. Повторяющихся при таком уточнении не может быть.

Или наоборот вводим Иван и ко всем Иванов, Ивановка, Иваново в обратной последовательности выбираем и подсовываем уточнения.

> [56] sniknik © (05.10.12 18:32)
> в базу пишешь его код

Лучше не привязываться к их кодам, они их меняют по 2 раза в год - тусуют что-нибудь туда сюда, то регионального поддчинения, то в составе города, то района, то ЗАТО какое вдруг станет. С названиями оно, правда, тоже так же.

← →
Inovet © (2012-10-05 19:50) [59]

> [57] asail © (05.10.12 18:52)
> Надо в БД географические координаты хранить. Потом уже по
> ним подставлять соответствующий город из справочника. :)

Вот это, наверное, будет лучше, ещё бы справочник такой был.

> [58] Inovet © (05.10.12 19:49)
> С названиями оно, правда, тоже так же.

В кладре хоть старые версии сохраняют, так что можно вытащить по старому новое. А про коды не помню.

> Лучше не привязываться к их кодам, они их меняют по 2 раза в год
http://habrahabr.ru/post/140378/
?

p.s. мы вынуждены завязываться на кладр... большинство агентов/клиентов по нему адреса сверяют.
но в основном не по коду, а по сумме названий, т.е. область ...... дом.
а вот ищется так как описал, по кодам.

> а вот ищется так как описал, по кодам.
в базе тоже код, и если поменяют, то повтор регистрации клиента, по введенному ранее, не совпадет. но пока "гейтс миловал".

> [61] sniknik © (05.10.12 19:55)
> http://habrahabr.ru/post/140378/

Ну вот не прошло и 15 лет (или сколько там). Давно пора.

asail © (05.10.12 18:52) [57]

> В интербэйсе может.

С диагностикой Lock conflict on no-wait transaction ?

Повбывав бы. Потому что результат второй транзакции напрямую зависит от окончания первой, и пока первая не закончится, вторая не знает, в какое непротиворечивое состояние нужно перевести базу данных.

> Повбывав бы.

Сдуру можно и лингам сломать.
Я к тому, что если стремиться максимально усложнить себе жизнь, ставить wait|nowait рандомно, уровень изоляции тоже рандомно ставить, то таки да, рано или поздно в задницу приехать можно. Только ты тогда ССЗБ.
Непонятно, правда, зачем asail © это вот всё приводит.

> Ega23 © (06.10.12 00:02) [65]

> Непонятно, правда, зачем asail © это вот всё приводит

Я про коллизии транзакций заговорил только с одной целью - убедить ТС не усложнять себе жизнь и не удалять записи из справочника. Ну, а дальше, как обычно - понеслась... :)

← →
Кщд (2012-10-09 17:55) [67]

> Дмитрий С © (04.10.12 00:25) [1]
> Подсчет ссылок просто.
> Update Cities set ref_count=ref_count+1 WHERE id=... при
> добавлении компании
>
> Update Cities set ref_count=ref_count-1 WHERE id=... при
> удалении.

Так делать не надо никогда.
В условиях многопользовательской БД, ref_count будет содержать числа, не имеющие отношения к реальности.

Подсчёт ссылок на строку таблицы в MySQL Найти похожие ветки