ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Как организовать связь между звездой: Центральная база - Много второстепенных баз
11 сообщений из 36, страница 2 из 2
  2  все
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678095
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
m1andryUUID_SHORT()
не стоит использовать...

код подразделения нужно вводить... как минимум в центральную БД
...
Рейтинг: 0 / 0
24.06.2014, 09:30:07
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678342
m1andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m1andry
Гость
Arm79m1andryUUID_SHORT()
не стоит использовать...

код подразделения нужно вводить... как минимум в центральную БД

Тоже сомневаюсь насчет него, так как неясна природа создания этого "случайно уникального" числа, но подкупает то, что тип поля INT, т.е. не прийдется перелопачивать весь код для внесения изменений с работой по ID типа String.
А как по-вашему мнению, почему UUID_SHORT() не стоит использовать?
...
Рейтинг: 0 / 0
24.06.2014, 12:10:16
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678345
m1andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m1andry
Гость
m1andry... не прийдется перелопачивать весь код для внесения изменений с работой по ID типа String.

У меня плейсхолдеры на ID везде ?i, но это то, что на поверхности. Пока не до конца осознаю, во что еще может вылиться смена первичного ключа на String.
...
Рейтинг: 0 / 0
24.06.2014, 12:12:27
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678349
m1andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m1andry
Гость
Arm79не стоит использовать...

Вот кстати еще один повод для сомнений.

Никак не пойму, отчего в MySQL столько мелочей-недоработок?
Почему нет возможности стандартными средствами хранить дерево в таблицах, а нужно мудрить костыли с Nested Tree?
Почему до 5.5 только на одно поле Timestamp можно было вешать CURRENT_TIMESTAMP?
Почему не оптимизирована работа с UUID (хранение, индексация, кластеризация и т.д.)?
Но это так, крик души)

Кстати, не посоветуете какой-нибудь простенький класс для работы с Nested Tree? Может сталкивались.
...
Рейтинг: 0 / 0
24.06.2014, 12:17:49
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678361
m1andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m1andry
Гость
А вот кстати по поводу кластеризации, оказывается в UUID_SHORT можно настраивать порядок формирования значения , т.е. что бы сначала шел timestamp вместо server_id, ну и наоборот.
Скажите пожалуйста, где выставляется этот самый server_id?
...
Рейтинг: 0 / 0
24.06.2014, 12:23:04
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678553
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
m1andryА как по-вашему мнению, почему UUID_SHORT() не стоит использовать?
Из-за этого:
The value of UUID_SHORT() is guaranteed to be unique if the following conditions hold:
* The server_id of the current host is unique among your set of master and slave servers
* Server_id is between 0 and 255
* You do not set back your system time for your server between mysqld restarts
* You do not invoke UUID_SHORT() on average more than 16 million times per second between mysqld restarts

Не переводить время, ограничения на ServerId, требование уникальности имени северов только в рамках вашей системы. В общем, если это не смущает, то можно выбирать.
m1andryНикак не пойму, отчего в MySQL столько мелочей-недоработок?
Покупайте Oracle или MS SQL :-)


m1andryПочему нет возможности стандартными средствами хранить дерево в таблицах, а нужно мудрить костыли с Nested Tree?
Это какие такие "стандартные" средства? Nested Tree - это лишь тип дерева, который реализуется везде. Чем вас не устраивает стандартные Id - ParentId?

m1andryПочему не оптимизирована работа с UUID (хранение, индексация, кластеризация и т.д.)?
Почему не оптимизирована? Вы с чем сравниваете то?
...
Рейтинг: 0 / 0
24.06.2014, 14:30:43
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38678688
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
javajdbc
Участник
Если нужны какие-то тонко-настроеные права
доступа, то имеет смысл создать отдельную колонку
created_by или,например source_db_id.
Вычислять на лету источник из ГУИД , я думаю, будет
небыстро (по сравнению с отдельной
проиндексированой колонкой)
...
Рейтинг: 0 / 0
24.06.2014, 16:17:32
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38679778
m1andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m1andry
Гость
javajdbcЕсли нужны какие-то тонко-настроеные права
доступа, то имеет смысл создать отдельную колонку
created_by или,например source_db_id.
Вычислять на лету источник из ГУИД , я думаю, будет
небыстро (по сравнению с отдельной
проиндексированой колонкой)

Подскажете, какое Ваше мнение насчет UUID() в качестве PK?
Все-таки CHAR(30), насколько удачно применять строчный первичный ключ?
Не будет заметной потери в производительности, если есть куча JOIN ON ID=parentID?
И также куча таблиц-связок одна-ко-многим (ID1, ID2), опять же, занимаемое место, или можно пренебречь?
...
Рейтинг: 0 / 0
25.06.2014, 14:37:40
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38679789
m1andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m1andry
Гость
Arm79m1andryПочему не оптимизирована работа с UUID (хранение, индексация, кластеризация и т.д.)?
Почему не оптимизирована? Вы с чем сравниваете то?

Сравниваю с обычным INT, или ошибаюсь? INT PK при AI пишется в индексе в конец, так как ID идет по возрастающей, а вот что будет с UUID, который постоянно генерируется с бухты-барахты?

Как вообще реализуется в крупных проектах PK? INT или делают и UUID?
...
Рейтинг: 0 / 0
25.06.2014, 14:40:18
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38679807
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
m1andryСравниваю с обычным INT, или ошибаюсь? INT PK при AI пишется в индексе в конец, так как ID идет по возрастающей, а вот что будет с UUID, который постоянно генерируется с бухты-барахты?

Как вообще реализуется в крупных проектах PK? INT или делают и UUID?

Смысл сравнивать с Int? Разумеется, ключ с последовательным рядом гораздо предпочтительнее. Для Guid в MS SQL сделали функцию NewSequentialId , которая возвращает уникальные возрастающие значения. Для MySql мне такой функции неизвестно.

С другой стороны, и я писал об этом ранее, недостатки GUID в данном контексте исправляются периодической переиндексацией.

Как в остальных крупных проектах мне неизвестно, но у меня GUID на всех таблицах (сущностях), которые могут участвовать в интеграции (включая репликацию), а это пользователи, заказы; а int - на незначащих таблицах. Например, разосланные e-mail, или записи в журнале событий, или классификаторы (словари), если нет натурального ключа, или идентификаторы объявлений...
...
Рейтинг: 0 / 0
25.06.2014, 14:51:19
| Ответить | Цитировать | Написать  
Как организовать связь между звездой: Центральная база - Много второстепенных баз
    #38680274
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
javajdbc
Участник
m1andryjavajdbcЕсли нужны какие-то тонко-настроеные права
доступа, то имеет смысл создать отдельную колонку
created_by или,например source_db_id.
Вычислять на лету источник из ГУИД , я думаю, будет
небыстро (по сравнению с отдельной
проиндексированой колонкой)

Подскажете, какое Ваше мнение насчет UUID() в качестве PK?
Все-таки CHAR(30), насколько удачно применять строчный первичный ключ?
Не будет заметной потери в производительности, если есть куча JOIN ON ID=parentID?
И также куча таблиц-связок одна-ко-многим (ID1, ID2), опять же, занимаемое место, или можно пренебречь?


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

Мой пост был скорее про логику --
по вашим словам надо как то различать
записи пришедших в центр из разных баз.
Это дополнительная задача к очевидной задачи
уникальности ИД в интегрированом контексте.

Вариантов примерно 3:

1. ид -- ГУИД или ГУИД+сервер_ид, исходную базу расшифровывать из ГУИД
2. ид -- составнойй ключ = локальный автоинкремент и сервер_ид
3. ид -- ГУИД и отдельное поле сервер_ид

Вариант 1 мне кажется неуклюжим -- необходимо расшифровывать на лету, плохая производительность
Вариант 2. составной ключ не очень удобен для многих фрейворков.
Вариант 3 обеспечивает оба функционала -- возможно слегка избыточная информация
...
Рейтинг: 0 / 0
25.06.2014, 19:20:33
| Ответить | Цитировать | Написать  
11 сообщений из 36, страница 2 из 2
  2  все
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Как организовать связь между звездой: Центральная база - Много второстепенных баз
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/search_topic.php?author=new+linux+user&author_mode=last_posts&do_search=1]:
 0ms
get settings:
 7ms
get forum list:
 11ms
get settings:
 6ms
get forum list:
 14ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 88ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 1ms
others: 436ms
total:  633ms
созд. / загр.: 633ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]