 Автор |
Сообщение |
Estet
Форумчанин
 |
|
Я так понял, что у вас по какой-то причине id строк в базах совпадать не будут и может случиться так, что вставляя строки в базу на девайсе, вы натолкнетесь на то, что строка с таким id уже существуют. Так вот, чтобы такого не произошло строки лучше идентифицировать с помощью guid'ов, а не int. Приэтом вы полностью сможете их копировать из базы в базу без риска дублирования.
И нельзя полагаться на производителей, в один прекрасный день номера деталей могут перестать быть уникальными и вам срочно придется пропатчить все устройства )) |
|
 |
|
 |
AlexRock
Гуру
 |
|
| Aprelle писал(а): |
недостаточно
ещё версию детали для данного каталожного номера нужно |
Не понимаю. Ты хочешь сказать, что каталожный номер этой детали какая-то другая деталь в будущем сможет занять? Этот каталожный номер - это своего рода Part Number или как там правильнее - это обозначение детали в общей конструкции машины, во всех чертежах - там для каждой мелочёвки даже свой номер есть. Это абсолютно уникальный номер для каждой детали, и если в БД айдишник этой детали может меняться (не важно, по каким причинам), то каталожный номер - никогда (разве что конструкцию изменят, но тогда просто этот номер будет удалён или изменён).
Или ты имеешь ввиду версию данных (старые или новые) для этой детали в БД на клиенте - не устарели ли, мол? Ну, так версия БД на сервере всегда в приоритете будет - синхронизация-то в одну сторону только идёт, так что в любом случае данные только с сервера на клиент передаются.
Или поясни, пожалуйста, что ты имел ввиду. |
|
| |
|
|
AlexRock
Гуру
|
|
| Estet писал(а): |
| Я так понял, что у вас по какой-то причине id строк в базах совпадать не будут и может случиться так, что вставляя строки в базу на девайсе, вы натолкнетесь на то, что строка с таким id уже существуют. Так вот, чтобы такого не произошло строки лучше идентифицировать с помощью guid'ов, а не int. Приэтом вы полностью сможете их копировать из базы в базу без риска дублирования. |
Ну, а разве недостаточно по каталожному номеру (обозначение/номер детали - парт намбер) их различать, как я выше написал? Или вы о каком-то особом типе данных guid говорите? У меня в MS SQL Server таких нет.
| Estet писал(а): |
| И нельзя полагаться на производителей, в один прекрасный день номера деталей могут перестать быть уникальными и вам срочно придется пропатчить все устройства )) |
Они не могут перестать быть уникальными - иначе их нельзя будет собрать. )) Если же обозначение детали будут менять, то новое будет явно не совпадать ни с одним существующим (ибо опять совпадение будет, что недопустимо), а это значит, что я просто запрошу деталь по старому обозначению и присвою ей новое обозначение на сервере, а на клиенте... Ааа! Понял - на клиенте-то не будут знать, что я для детали новое обозначение присвоил и не смогут обновиться по старому обозначению... Хмм, тогда действительно нужно какое-то уникальное обозначение для детали придумывать, которое бы не менялось при любых изменениях айдишников и парт намберов. Вы (в т. ч. и Апрель) это имели ввиду? |
|
| |
|
|
Aprelle
Гуру
|
|
| AlexRock писал(а): |
| сли в БД айдишник этой детали может меняться (не важно, по каким причинам), то каталожный номер - никогда (разве что конструкцию изменят, но тогда просто этот номер будет удалён или изменён). |
так вот ты и определись, что будет происходить при изменении конструкции детали, будет ли меняться её номер или нет? а у деталей, в состав которых входит деталь с изменившимся номером? вот поэтому в PLM кроме каталожного номера есть еще и версия, на предприятиях часто бывает вносят изменения/доработки в конструкцию/деталь и оставляют прежний каталожный номер, просто версию увеличивают. |
|
| |
|
|
AlexRock
Гуру
|
|
| Aprelle писал(а): |
| вот поэтому в PLM кроме каталожного номера есть еще и версия, на предприятиях часто бывает вносят изменения/доработки в конструкцию/деталь и оставляют прежний каталожный номер, просто версию увеличивают. |
А, ты вот про какую версию - я смотрел документацию - там версий в самом (ещё бумажном) каталоге не было. Ну, это я тогда посоветуюсь - там ещё свои нюансы, типа того, что данные модели сняты с производства и конструкция меняться точно не будет, или будет меняться так, что вся модель получит постфиксное обозначение и будет фактически новая БД для этой модели. |
|
| |
|
|
Estet
Форумчанин
|
|
Create DataBase Test
GO
use Test
Create table test
(
id uniqueidentifier rowguidcol primary key default(newid())
)
insert into test
Default values
Погляди данные в этой таблице. Вот так выглядят Guid'ы. Они точно уникальны. |
|
| |
|
|
Aprelle
Гуру
|
|
| а теперь сравни, во сколько раз увеличится объем трафика и вычислительная нагрузка при простом сравнении ид-шников. |
|
| |
|
|
Estet
Форумчанин
|
|
| Трафик увеличится - да, нагрузка - незначительно. Первичные ключи, ты знаешь, кластеризованные(т.е. физически располагаются в отсортированном порядке) |
|
| |
|
|
Aprelle
Гуру
|
|
| при автоинкрементных ид-шниках не нужно весь список гнать, достаточно номер последнего и список удаленных, суммарные затраты на порядок меньше. |
|
| |
|
|
Estet
Форумчанин
|
|
тут вопрос вот в чем, если информация в базе будет часто обновляться и канал будет критичен к трафику (GPRS), то можно автоинкрементные ID, иначе можно(и нужно я считаю) использовать guid'ы.
Кстати, почему в базах будут отличаться идентификаторы строк? |
|
| |
|
|
AlexRock
Гуру
|
|
| Estet писал(а): |
| Кстати, почему в базах будут отличаться идентификаторы строк? |
Потому что на сервере могут сильно БД изменить, пока клиент надумает синхронизироваться. Например, достаточно такой дурацкой ситуации, когда сначала одну деталь уберут из конструкции, а потом введут обратно - уже айдишник другой. Даже просто пользователь может не обновить данные по детали, а сначала удалить её, а потом снова ввести, но уже с новыми параметрами.
| Estet писал(а): |
Create DataBase Test
GO
use Test
Create table test
(
id uniqueidentifier rowguidcol primary key default(newid())
)
insert into test
Default values
Погляди данные в этой таблице. Вот так выглядят Guid'ы. Они точно уникальны. |
Я же писал, что я новичок. )) Тут в новой БД таблица создаётся и в ней столбцы определяются? Где тут гуид и какую роль он играет? Объясните поподробнее, пожалуйста. |
|
| |
|
|
Estet
Форумчанин
|
|
Так вам в любом случае придется проделать все тоже самое и в базах на девайсах. Если строка на сервере будет удалена и снова добавлена с другими параметрами, вам придется сделать тоже самое на девайсах. Разве нет?
Да создается база со одной таблицей с одной колонкой. В нее могут вставлять только уникальные значения, сформированные в виде Guid.
Можно было просто открыть базу в Management studio и посмотреть, че в ней там есть ))
Guid выглядит вот так:'22345200-abe8-4f60-90c8-0d43c5f6c0f6'
Во множестве можно встретить в реестре Windows. |
|
| |
|
|
AlexRock
Гуру
|
|
| Estet писал(а): |
| Если строка на сервере будет удалена и снова добавлена с другими параметрами, вам придется сделать тоже самое на девайсах. Разве нет? |
Ну, это как организовать синхронизацию, я думаю. Если сначала отыскивать удалённые, а потом добавлять новые, то придётся повторить. А если как-то по-умному учесть вот такие выкрутасы на сервере, то, по сути, нужно будет только отследить парт намбер детали, и по такому же парт намберу обновить параметры.
| Estet писал(а): |
Да создается база со одной таблицей с одной колонкой. В нее могут вставлять только уникальные значения, сформированные в виде Guid.
Можно было просто открыть базу в Management studio и посмотреть, че в ней там есть ))
Guid выглядит вот так:'22345200-abe8-4f60-90c8-0d43c5f6c0f6'
Во множестве можно встретить в реестре Windows. |
Я даже не понимаю, что это за код вы написали. )) Ну, а то, что можно уникальными все ячейки столбца сделать, я знаю. Т. е. Guid - это просто название стобца у вас, или это какой-то особый тип данных? Не вижу такого типа в Management Studio. |
|
| |
|
|
Estet
Форумчанин
|
|
| Цитата: |
Ну, это как организовать синхронизацию, я думаю. Если сначала отыскивать удалённые, а потом добавлять новые, то придётся повторить. А если как-то по-умному учесть вот такие выкрутасы на сервере, то, по сути, нужно будет только отследить парт намбер детали, и по такому же парт намберу обновить параметры. |
Я думаю первый вариант все же лучше.
Во-первых, проблем меньше.
Во-вторых, ID у строк на всех базах будут одинаковые.
| Цитата: |
Я даже не понимаю, что это за код вы написали. )) Ну, а то, что можно уникальными все ячейки столбца сделать, я знаю. Т. е. Guid - это просто название стобца у вас, или это какой-то особый тип данных? Не вижу такого типа в Management Studio. |
Тип - uniqueidentifier. rowguidcol - говорит о том, что вставлять можно только данные вида GUID. GUID - это 128 битная последовательность. Каждый GUID уникален, потому что 2 в степени 128 это очень много. Таким образом с помощью него можно идентифицировать строки и быть уверенным, что строки повторяться не будут ))
Primary key говорит о том, что столбец является первичным ключом.
default(newid()) говорит о том, что когда вы будете вставлять строку в эту таблицу и не укажете для этого столбца значение, вставится значение по-умолчанию. Значение по-умолчанию генерируется функцией newid()
как то так ))
Если удастся сделать так, чтобы строки имели одинаковый ID на всех базах, то будет гораздо проще и можно будет использовать int.Последний раз редактировалось: Estet (Пн 8-03-10 : 02-33), всего редактировалось 1 раз |
|
| |
|
|
Estet
Форумчанин
|
|
вот так выглядит кусок реальной базы на Guid'ах
 |
|
| |
|
|
AlexRock
Гуру
|
|
| Estet писал(а): |
| Если удастся сделать так, чтобы все строки имели одинаковый ID, то будет гораздо проще и можно будет использовать int. |
Таки да, если повторять все серверные операции на клиенте, то можно сохранить одинаковость айди, но это нужно где-то записывать все транзакции на сервере, а потом передать этот лог на клиент, где и повторить его. Я даже не знаю - это что-то типа своего формата записи всех действий с БД в лог разработать надо, а ещё механизм чтения этого лога на клиенте, если нет уже встроенных возможностей для такого в самой СУБД. Я просто пока не изучал настолько подробно документацию по MS SQL Server. |
|
| |
|
|
Estet
Форумчанин
|
|
Да бросьте вы! Используйте тот же синтаксис SQL. Зачем изобретать велосипед? ))
Да и то, если в СУБД уже нет встроенных возможностей генерить скрипты изменений за определенный промежуток. Я если честно не знаю ) |
|
| |
|
|
AlexRock
Гуру
|
|
| Кстати, мне MS SQL Server предлагает использовать соединение к БД, где либо "сама БД на сервере" будет (т. е строка соединения выглядит как "Имя_сервера(компьютера)\Имя_сервера(службы)\Имя_БД"), либо отдельно файл БД. Что лучше указывать - БД, "вертящуюся" на сервере, или просто один файл, и почему? |
|
| |
|
|
mrabs
Форумчанин
 |
|
| AlexRock писал(а): |
| А если как-то по-умному учесть вот такие выкрутасы на сервере, то, по сути, нужно будет только отследить парт |
Я бы не рекомедовал особенно замороченнные алгоритмы синхронизации баз. Никакие алгоритмы не опишут фантазии пользователей, а это - головная боль разработчика. |
|
| |
|
|
AlexRock
Гуру
|
|
Так, и ещё основная проблема, из-за которой я не могу Sync Services использовать. Вот, если я к БД из Интернета обращаюсь, то я использую в строке соединения внешний айпи сервера, а если я с коммуникатора, который по USB подключен и вообще с локального устройства, то какой айпи указывать? Ведь в локалке у сервера много внутренних айпишников, т. к. на нём куча сетевых устройств. Может, тот айпишник, который в соединении в Винде появляется, когда коммуникатор по УСБ цепляешь к компьютеру (там в Windows Seven новое соединение появляется).
Такой же вопрос, если в локалке пытаешься соединиться к БД через вай-фай - там в строке соединения нужно айпи точки доступа указывать, или той сетевой платы на сервере, которая с точкой доступа соединена?
Ведь по сути и внешний айпи сервера, это не айпи сервера на самом деле, а айпи сетевой карты, которая на сервере смотрит в Интернет.
Какой принцип вообще при указании адреса в строке соединения? Нужно указывать айпи первого устройства, к которому клиент подсоединяется, или как? Т. е. есть, например, длинная цепочка "сервер-сетевая плата на сервере-точка доступа-ещё любые йстройства-клиент". И у каждого звена свой айпи. Так какой айпи указывать в строке соединения, если БД на сервере? И соответственно порт указывать на каком устройстве - сервере, или того устройтсва, которого айпи указываешь? |
|
| |
|
|
|
Аватары: Вкл|Выкл ЮзерИнфо: Вкл|Выкл Подписи: Вкл|Выкл
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете вкладывать файлы
Вы можете скачивать файлы
|
|
