 Автор |
Сообщение |
leoboec
Эксперт
 |
|
в общем вопрос касается MySQL надо сделать несколько таблиц связав их между собой (так как я в sql новичек нужна Ваша помощь) онимаю что вроде по первичному ключу.. связь.. но все равно точно понять не могу.... собственно жду подсказок  связь таблиц примерно так как на прикрепленном рисунке
| бд.JPG |
| Описание: |
|
| Размер файла: |
24.74 KB |
| Просмотрено: |
254 раз(а) |
|
|
|
 |
|
 |
Richard Ferlow
Гуру
 Предупреждений : 2
|
|
Создаешь таблицу где поле ID autoincrement, и еще есть поле ParentID помимо Name и прочего.
Ну дальше просто -
Главные категории будут с ParentID 0
Вложенные будут ParentID иметь согласно тому какой категории принадлежат. |
|
| |
|
|
leoboec
Эксперт
|
|
ага вот про автоинкримент я как раз подумал.. потому что с ним прикольно вроде получается... так и я так понимаю что автоинкримент для каждой таблицы надо содавать.. типа нумерация внутри таблиц.. про ParentID суть понял... но можно немного поконкретнее ?? то есть это тоже ID для связи именно таблиц между родительскими и дочерними?!
и сразу следующий вопрос возникает... скажем я работаю с этой БД на локальном компьютере и есть точно такая же на серваке... вот проблема синхронизации.. как мне проверять и тем более заливать на сервер новы/измененные строки.. получается если таблица скажем 100000 строк то время оэидания будет большое.. можно ли как то такое реализовать, чтобы проссматривать только измененные на локальном компьютере (скажем я думал о дополнительном поле что-то типа дата изменения..)
заранее благодарен |
|
| |
|
|
Richard Ferlow
Гуру
Предупреждений : 2
|
|
...да вроде 100к не так уж много =) не сделаете дамп архивом и выгрузите.
ну так да, можно поизобретать экспорт с заданной датой...дату...ну мне нравится порсто при создании записи time() в отдельную ячейку вписывать.
А так посмотрите SypexDumper - большие дампы там не проблема, я бы ей делал при случае....
В описанном вами случае таблица одна всего будет(Бытовая техника), где весь каталог и будет храниться. Однако если другая техника будет то смотря какая задача, может тоже стоит ту же таблицу использовать.
Смотря сколько у вас товаров, если прям огроменное кол-во будет, то имеет смысл структура пунктов хранить в одной таблице, а сами товары уже в другой, так проще будет.
ParentID вручную будете добавлять.
например
Бытовая тахника - ID - 1 Parentid - 0
Телефония - ID 2 - Parentid - 0
ТВ - ID 3 - ParentID 1
LCD - ParentID - 3
Обычные - ParentID - 3
и т.д. - |
|
| |
|
|
leoboec
Эксперт
|
|
эм... нет нет ) на моем рисунке как раз не однеа таблица )) то есть есть общая таблица основная а есть таблица она как бы не вложенная.. она связана просто с первой таблицей (то есть конкретно с ячейкой ТВ) далее у таблицы о ТВ есть своя таблица.. (они все раздельны!!! это не одна таблица) может это и глупо но сейчас проект требует именно таких действий
зы.. пардон случайно так вставилосПоследний раз редактировалось: leoboec (Пн 24-05-10 : 18-48), всего редактировалось 1 раз |
|
| |
|
|
leoboec
Эксперт
|
|
| Richard Ferlow писал(а): |
...да вроде 100к не так уж много =) не сделаете дамп архивом и выгрузите.
ну так да, можно поизобретать экспорт с заданной датой...дату...ну мне нравится порсто при создании записи time() в отдельную ячейку вписывать.
А так посмотрите SypexDumper - большие дампы там не проблема, я бы ей делал при случае....
В описанном вами случае таблица одна всего будет(Бытовая техника), где весь каталог и будет храниться. Однако если другая техника будет то смотря какая задача, может тоже стоит ту же таблицу использовать.
|
эм... нет нет Smile) на моем рисунке как раз не однеа таблица Smile)) то есть есть общая таблица основная а есть таблица она как бы не вложенная.. она связана просто с первой таблицей (то есть конкретно с ячейкой ТВ) далее у таблицы о ТВ есть своя таблица.. (они все раздельны!!! это не одна таблица) может это и глупо Smile но сейчас проект требует именно таких действий Smile
| Richard Ferlow писал(а): |
Смотря сколько у вас товаров, если прям огроменное кол-во будет, то имеет смысл структура пунктов хранить в одной таблице, а сами товары уже в другой, так проще будет.
ParentID вручную будете добавлять.
например
Бытовая тахника - ID - 1 Parentid - 0
Телефония - ID 2 - Parentid - 0
ТВ - ID 3 - ParentID 1
LCD - ParentID - 3
Обычные - ParentID - 3
и т.д. - |
да тут даже дело не в количестве товара а в том что НАДО сейчас так сделать )) |
|
| |
|
|
Richard Ferlow
Гуру
Предупреждений : 2
|
|
leoboec
...эм...мне кажется, вы ошибаетесь с таким подходом
Ну в любом случае через ParentID у вас связь...но при этом где-то надо будет хранить даннные какая таблица какой принадлежит, что в прямом пути - в таблице ТВ какие таблицы лежат, что и в обратном - Конкретный товар каким таблицам принадлежит(полный путь имеется ввиду) |
|
| |
|
|
leoboec
Эксперт
|
|
да понятно, что ошибаюсь но просто идей на другие таблицы не хватает то есть я правильно понимаю:
Таблица Бытовая техника сотоит скажем ТВ(ключ1) микроволновка и тд
далее таблица ТВ состоит из столбцов lcd обычны и тд (сама таблица должна быть связана с первой по ключу 1 но при этом у нее должен быть ключ2 который связывает ее с 3 таблицей) и так для всех вложенных таблиц?! |
|
| |
|
|
Richard Ferlow
Гуру
Предупреждений : 2
|
|
Вот такую структуру можно в пределах одной таблицы реализовать через ID и ParentID
как вы предлагаете - так стоит делать только если четко понимаете, зачем вам нужно именно так. |
|
| |
|
|
leoboec
Эксперт
|
|
мне нужно именно так для проекта, чтобы защитить диплом, никуда далее этот проект не пойдет... в проекте должно быть несколько таблиц около 10.. вот я и придумал сделать вот такое разделение... потому что другого не могу придумать...  к сожалению |
|
| |
|
|
Richard Ferlow
Гуру
Предупреждений : 2
|
|
Сразу бы сказали так =)
ну я так вроде бы все объяснил =) |
|
| |
|
|
leoboec
Эксперт
|
|
| ага спасибо большое )) буду сегдоня пытаться структуру эту всю воссоздать если что еще сюда отпишусь.. но суть я уловил правильно?? что типа у каждой таблицы получается есть два ключа пок оторым она связана с предыдущей (родительской) и дочерней?! верно?! |
|
| |
|
|
AlexRock
Гуру
 |
|
| leoboec писал(а): |
| вот проблема синхронизации |
Эмм, я как бы тоже сейчас этим занимаюсь. Я решил просто скопировать модель синхронизации с той, что WCF предлагает. Т. е. для каждой таблицы твоей БД заводится ещё по паре столбцов ("Время последнего редактирования" и "Время добавления") и по одной таблице для хранения удалённых записей (ибо как ты будешь синхронизировать те данные, которые на сервере уже удалены? - клент-то о них не узнает уже). Таблица хранения удалёнок состоит из идентификатора удалённой записи и времени её удаления.
Синхронизация просиходит так: сначала выбираются удалёнки из таблиц удалёнок, потом выбираются вставки по столбцам "Время добалвения" (сравнивается время последней синхронизации клиента и "Время добавления" для каждой записи), потом выбираются изменёнки по столбцу "Время последнего редактирования" (опять по времени синхронизации клиента сравнение). Как-то так. Подробнее можно глянуть тут. СУБД не важна тут - главное, принцип.
Там же про пакетирование можно почитать, чтобы твои транзакции на сотни и тысячи записей с большими объёмами данных (картинки, большие тексты и пр.) не потерялись и не стали жертвой недостатка памяти. |
|
| |
|
|
leoboec
Эксперт
|
|
| ага а можно про таблицу удаленок поподробнее???? для каждой таблицы я создаю дополнительную таблицу в которой содержатсья удаленные элементы??? и соответственно вопрос... скажем если я в главной таблице удаляю строку следовательно мне нужно удалить и все записи из подчиненных таблиц... и получается для каждого уровня будут свои таблицы из которых последовательно все и удаляется??? или как? |
|
| |
|
|
AlexRock
Гуру
|
|
| AlexRock писал(а): |
| потом выбираются вставки по столбцам "Время добалвения" (сравнивается время последней синхронизации клиента и "Время добавления" для каждой записи), потом выбираются изменёнки по столбцу "Время последнего редактирования" (опять по времени синхронизации клиента сравнение) |
Кстати, если при добавлении записи в таблицу заполнять каким-нибудь скриптом или триггером (чего там у вас с СУБД есть) столбец "Время последнего редактирования" тем же значением, что и в "Время добавления", то фактически при синхронизации с сервера можно не запрашивать столбец "Время добавления", ибо это будут те же данные, что и в столбце "Время последнего редактирования", т. е. всего два запроса придётся сделать - по столбцу изменений, и по столбцу удалений (в таблице удалёнок), вместо запросов по трём столбцам. Я сейчас так написал код, только ещё не протестировал. ))
| leoboec писал(а): |
| для каждой таблицы я создаю дополнительную таблицу в которой содержатсья удаленные элементы??? и соответственно вопрос... скажем если я в главной таблице удаляю строку следовательно мне нужно удалить и все записи из подчиненных таблиц... и получается для каждого уровня будут свои таблицы из которых последовательно все и удаляется??? или как? |
Угу. Если сделать триггеры, то всё будет удаляться автоматом - в таблицах связей будут удаляться по правилам удаления при создании связей (у меня это в мастере создания таблиц выбирается), а в таблицах удалёнок - по триггерам удаления. Только я пользуюсь уже готовой такой реализацией от WCF - у меня в первоначальной БД мастер сам создаёт для каждой таблицы эти дополнительные столбцы и таблицу удалёнок и добавляет к ним триггеры. Например, для таблицы Table1 в базе данных dbpic2008 есть триггер, который заполняет талбицу удалёнок (Table1_Tombstone) после каждого удаления записи из таблицы Table1:
Здесь используется СУБД MS SQL Server 2008 Express, а триггер написан на Transact-SQL.
Это всего лишь один из вариантов реализации. Я сначала думал, что данные об удалении записей можно помещать в исходную же таблицу Table1, но потом решил не заморачиваться и просто передрать уже готовый вариант, предложенный Microsoft.Последний раз редактировалось: AlexRock (Чт 27-05-10 : 18-04), всего редактировалось 1 раз |
|
| |
|
|
leoboec
Эксперт
|
|
| да и еще вопрос... столбцы дата создания и дата редактирования по идее можно же сделать невидимыми??? они же нужны только для программы.. пользователю видеть их не надо? верно я думаю? |
|
| |
|
|
AlexRock
Гуру
|
|
| leoboec писал(а): |
| да и еще вопрос... столбцы дата создания и дата редактирования по идее можно же сделать невидимыми??? они же нужны только для программы.. пользователю видеть их не надо? верно я думаю? |
Хмм, а первоначально вообще БД пользователю не видна - что ты из БД считаешь и покажешь пользователю, то и будет видно. Ты, наверное, имеешь ввиду, когда с помощью внутренних механизмов среды программирования тебе готовую таблицу с данными (dataGrid, например) создают по таблице из БД. В Вижуале можно в мастере выбрать, какие столбцы отображать, а если руками делать такие датагриды, то сам назначаешь его состав.
Прямо в самой БД делать невидимые столбцы смысла нет, ибо зачем это? |
|
| |
|
|
leoboec
Эксперт
|
|
| да и еще разок про ключи точнее про Parrent 0 1 и так далее.. можно уточнение... итак первая таблица бытовая техника у нее есть общий ключ который связывает ее с вложенными таблицами второго уровня?? у таблиц второго уровня есть свои ключи которые связывают из с таблицами третьего уровня?? верно я понимаю??? и может ли этим ключом быть автоинкримент??? по идее уникальный номер?! |
|
| |
|
|
leoboec
Эксперт
|
|
| AlexRock писал(а): |
| leoboec писал(а): |
| да и еще вопрос... столбцы дата создания и дата редактирования по идее можно же сделать невидимыми??? они же нужны только для программы.. пользователю видеть их не надо? верно я думаю? |
Хмм, а первоначально вообще БД пользователю не видна - что ты из БД считаешь и покажешь пользователю, то и будет видно. Ты, наверное, имеешь ввиду, когда с помощью внутренних механизмов среды программирования тебе готовую таблицу с данными (dataGrid, например) создают по таблице из БД. В Вижуале можно в мастере выбрать, какие столбцы отображать, а если руками делать такие датагриды, то сам назначаешь его состав.
Прямо в самой БД делать невидимые столбцы смысла нет, ибо зачем это? |
ну как бы да я примерно это и имел ввиду )) хотя может быть и не это.. суть проекта в общем такая... у меня есть какая то БД состоящая скажем из 10 таблиц.. и точно такая же бд есть на сервере с такими же таблицами.. то есть пользователь видит сами таблицы.. но у меня же таблицы (так как есть синхронизация ) содержат столбцы дата создания и дата редактирования... но эти столбцы даром не нужны пользователю! то есть он их видеть не должен... соответственно я их сходу ставлю visible= false и не напрягаюсь.. верно? |
|
| |
|
|
AlexRock
Гуру
|
|
| leoboec писал(а): |
| да и еще разок про ключи точнее про Parrent 0 1 и так далее. |
| Richard Ferlow писал(а): |
и еще есть поле ParentID помимо Name и прочего.
Ну дальше просто -
Главные категории будут с ParentID 0
Вложенные будут ParentID иметь согласно тому какой категории принадлежат. |
А я не понял, зачем Ричард вообще предложил пэаранты делать? Разве что для явного обозначения иерархичской классификации бытовой техники? Можно просто связать таблицы обычными отношениями родитель-потомок (а в этих отношениях прописать правила удаления-редактирования), а эта иерархия будет прослеживаться косвенно, а не явно через лишние данные в виде ПэарантАйди0 и т. д.
У меня всё сделано вот через такие отношения:
Вот так у меня создаются отношения - тут видно, что для отображения иерархии не нужны дополнительные поля типа ПэарантАйди и т. п. - всё делается через первичные и внешние ключи (тут в окне данные по умолчанию при открытии окна создания нового отношения - поэтому не совпадают с данными на рисунке сверху):
Если сильно надо, можешь нарисовать себе на листочке схемы БД, где эту иерархию можешь отобразить стрелками со связями и расположив таблицы на разном уровне - для СУБД это не будет иметь никакого значения, ей только отношения (relations) важны.Последний раз редактировалось: AlexRock (Чт 27-05-10 : 18-36), всего редактировалось 1 раз |
|
| |
|
|
|
