A
понял
Size: a a a
2021 March 17
A
спасибо огромное
IZ
Art
Привет. хотел бы задать такой вопрос зачем нужно создавать таблицы с отдельными сущностями, к примеру есть таблица Employee и у него должно быть поле должность, так почему бы просто не создать в таблице сотрудника текстовое поле position ? Вместо ето-го нужно создать отдельную таблицу для должностей.
Вопрос: так чем же такой подход лучше ?
Вопрос: так чем же такой подход лучше ?
1) экономия объема данных
2) устранение аномалий в данных, когда одна и та же должность называется по разному.
2) устранение аномалий в данных, когда одна и та же должность называется по разному.
A
1) экономия объема данных
2) устранение аномалий в данных, когда одна и та же должность называется по разному.
2) устранение аномалий в данных, когда одна и та же должность называется по разному.
Опа, благодарю
IZ
Art
Я действительно не знаю какой лучше
N1
A
понял
IZ
Art
если нужно будет изменить какй-то елемент то в первом варианте не прийдеться идти по всмем сотрудникам
Это тоже важное замечание
Э
Здравствуйте. Делаю простенький сервис по покупкам авиобилетов онлайн. Хотел бы спросить это нормальная модель? Сам только недавно начал этим заниматься так что хотел бы узнать совет опытных людей.
Вверху пишется только первичный ключ. Также я вижу, что тут много чего можно вынести в отдельные таблички. К примеру, можно вынести в отдельную таблицу тип карты, расписание, и т.д.
Если это Erwin, то логическую структуру можно, вроде как, и на русском делать.
Если это Erwin, то логическую структуру можно, вроде как, и на русском делать.
e
Вверху пишется только первичный ключ. Также я вижу, что тут много чего можно вынести в отдельные таблички. К примеру, можно вынести в отдельную таблицу тип карты, расписание, и т.д.
Если это Erwin, то логическую структуру можно, вроде как, и на русском делать.
Если это Erwin, то логическую структуру можно, вроде как, и на русском делать.
Спасибо,но я уже давно выкинул эту модель в мусорку. С нуля ещё раз делаю
2021 March 18
Э
Спасибо,но я уже давно выкинул эту модель в мусорку. С нуля ещё раз делаю
G
Добрый день.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
KR
Добрый день.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
А почему внешние ID не хранить бы в самих таблицах сущностей?
IZ
Добрый день.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
Я вот лично не понял вопрос вообще.
KK
Добрый день.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
Имеется таблица под интеграции с внешними сервисами, в которой складируются связки ID нашей системы и ID из внешней. Таковых сущностей много, но полей под это заведено два - entity_id и entity_type.
Сейчас возникла необходимость фиксировать FK на связанные таблицы сущностей (чтобы, например, реализовать их удаление при удалении в синхронизируемом сервисе), однако задать несколько связных таблиц на одну колонку в таблице не получится, как я понимаю.
Есть ли какие грамотные решения? (Варианты создания по колонке на каждую сущность и после объединение при сериализации уже рассматривалось, на ряду с триггерами)
В стеке используется SQLAlchemy + PostgreSQL.
У вас разные провайдеры данных и эти данные лежат в одной таблице? entity_type- провайдер? Если entity_type - это ваша внутренняя таблица, тогда вариант @tyranron на мой взгляд, лучше всего подходит для вас
G
А почему внешние ID не хранить бы в самих таблицах сущностей?
Межсистемная синхронизация.
Около года назад мы начинали с этого, но в итоге ушли от такой системы из-за недостаточной гибкости.
Понял, дал недостаточно контекста. Сейчас я покажу таблицу целиком.
Около года назад мы начинали с этого, но в итоге ушли от такой системы из-за недостаточной гибкости.
Понял, дал недостаточно контекста. Сейчас я покажу таблицу целиком.
G
Таблица выглядит вот так. Собственно:
id - id самой записи
entity_id - id в нашей системе. То самое поле, из-за которого вопрос, каким образом его можно привязать к реальным сущностям в других таблицах, особенно в случае удаления этой сущности или удаления этой записи о сущности: триггером с какой-то процедурой перебора по тайпам, какой-то виртуальной таблицей/колонкой, хз.
entity_type - enum (пока что), что это именно: проект, таска, лог, журнал, запись, etc.
external_provider - enum (пока что), т.к. пока что поддерживаем ограниченное количество связываемых систем, обозначающий скорее общее название сервиса, т.к. мы работаем в том числе с self-hosted решениями и обслуживаем сразу нескольких. В этом случае провайдер будет один, а сурс будет отличаться
external_source - url, важно в случае self-hosted вариантов чужих систем
external_additional_data - понятно.
id - id самой записи
entity_id - id в нашей системе. То самое поле, из-за которого вопрос, каким образом его можно привязать к реальным сущностям в других таблицах, особенно в случае удаления этой сущности или удаления этой записи о сущности: триггером с какой-то процедурой перебора по тайпам, какой-то виртуальной таблицей/колонкой, хз.
entity_type - enum (пока что), что это именно: проект, таска, лог, журнал, запись, etc.
external_provider - enum (пока что), т.к. пока что поддерживаем ограниченное количество связываемых систем, обозначающий скорее общее название сервиса, т.к. мы работаем в том числе с self-hosted решениями и обслуживаем сразу нескольких. В этом случае провайдер будет один, а сурс будет отличаться
external_source - url, важно в случае self-hosted вариантов чужих систем
external_additional_data - понятно.
Х
Ребят, всем привет. Есть кто, кто бы мог посоветовать по SISS скриптам. Есть скрипт написаный на студии 2017, с последней версией тулзов(ну там пакет вусякой-всячины для разработки скриптов работы с бд). А мне нужно перенести всё на версию студии 2010, а оно пекедж просто не может открыть, пишет, что инвалидный xml. Кто не будь сталкивался с подобным, есть какие-небудь советы, полезные линки ?
Ато в нете я нашёл один единственный пост связаный с таким конфьюзом
Ато в нете я нашёл один единственный пост связаный с таким конфьюзом
Л
Year() а вообще в гугл забить этот вопрос и первая ссылка
IK
Таблица выглядит вот так. Собственно:
id - id самой записи
entity_id - id в нашей системе. То самое поле, из-за которого вопрос, каким образом его можно привязать к реальным сущностям в других таблицах, особенно в случае удаления этой сущности или удаления этой записи о сущности: триггером с какой-то процедурой перебора по тайпам, какой-то виртуальной таблицей/колонкой, хз.
entity_type - enum (пока что), что это именно: проект, таска, лог, журнал, запись, etc.
external_provider - enum (пока что), т.к. пока что поддерживаем ограниченное количество связываемых систем, обозначающий скорее общее название сервиса, т.к. мы работаем в том числе с self-hosted решениями и обслуживаем сразу нескольких. В этом случае провайдер будет один, а сурс будет отличаться
external_source - url, важно в случае self-hosted вариантов чужих систем
external_additional_data - понятно.
id - id самой записи
entity_id - id в нашей системе. То самое поле, из-за которого вопрос, каким образом его можно привязать к реальным сущностям в других таблицах, особенно в случае удаления этой сущности или удаления этой записи о сущности: триггером с какой-то процедурой перебора по тайпам, какой-то виртуальной таблицей/колонкой, хз.
entity_type - enum (пока что), что это именно: проект, таска, лог, журнал, запись, etc.
external_provider - enum (пока что), т.к. пока что поддерживаем ограниченное количество связываемых систем, обозначающий скорее общее название сервиса, т.к. мы работаем в том числе с self-hosted решениями и обслуживаем сразу нескольких. В этом случае провайдер будет один, а сурс будет отличаться
external_source - url, важно в случае self-hosted вариантов чужих систем
external_additional_data - понятно.
О, понял о чем вы. Аналогичная задача. Вообще говоря, обычно в транзакции просто везде где видел заворачивается создание сущности в нескольких таблицах.
А так – триггер звучит как вариант. Но только в том случае, если не требуется дополнительной метаинформации / дополнительная метаинформация дублируется в конкретной таблице
А так – триггер звучит как вариант. Но только в том случае, если не требуется дополнительной метаинформации / дополнительная метаинформация дублируется в конкретной таблице