ЕК
Где деньги лежат
Size: a a a
2020 June 03
ЕК
А я пошёл спать)
ЕК
Но на самом деле, я им тоже пользовался, всё ок было
RK
вроде все изи работает
Gt
IDE
ну короче у меня щас вот такая тема
Была такая же тема, долго в офисе бились, в итоге перевели все сайты на другой стек. 😃
YS
Name role ключи. А вот без них пихни что нить?))
RK
что например?)
YS
Не за клипом сейчас. Завтра не забуду скину.
RK
YS
что например?)
Ну вот такой запрос мне с Http не получилось сделать.
https://developer.vimeo.com/api/upload/videos#resumable-approach-step-2
https://developer.vimeo.com/api/upload/videos#resumable-approach-step-2
RK
А ну так для атача же есть отдельное свойство
YS
Не работает. Так как надо.
RK
Странно
YS
Ну может я что натупил. За компом буду в постман вроде остались примеры. Скину. Сейчас с мобилы.
VY
вопрос по архитектуре БД:
имеется 6 моделей (книжный каталог):
Юзеры (дефолтная)
Авторы (отдельная, не юзеры)
Книги,
Категории,
Жанры,
Тэги
также еще 2 служебные (пока не уверен, что они действительно нужны):
Типы_свойств,
Значения_свойств (для предустановленных) - каждому типу свой набор значений.
Дальше таблица связи модели-типы-значения...
Вот эта таблица меня беспокоит :)
Подразумевается, что свойства всех моделей, которые много-ко-многим - хранятся в этой таблице...
Может это неверный подход?
ее структура
entity_id bigIncrements
entity string
type_id bigIncrements
values_id bigIncrements
1-е - это поле entity - имя модели - оно тут как-то не к месту.
Как поступить?
для свойств много-ко-многим:
1) Делать для имен моделей отдельную таблицу? И дальше юзать эту хитрую таблицу связей?
2) Или свойства моделей более целесообразно хранить отдельно для каждой модели ? Со своей таблицей связей?
имеется 6 моделей (книжный каталог):
Юзеры (дефолтная)
Авторы (отдельная, не юзеры)
Книги,
Категории,
Жанры,
Тэги
также еще 2 служебные (пока не уверен, что они действительно нужны):
Типы_свойств,
Значения_свойств (для предустановленных) - каждому типу свой набор значений.
Дальше таблица связи модели-типы-значения...
Вот эта таблица меня беспокоит :)
Подразумевается, что свойства всех моделей, которые много-ко-многим - хранятся в этой таблице...
Может это неверный подход?
ее структура
entity_id bigIncrements
entity string
type_id bigIncrements
values_id bigIncrements
1-е - это поле entity - имя модели - оно тут как-то не к месту.
Как поступить?
для свойств много-ко-многим:
1) Делать для имен моделей отдельную таблицу? И дальше юзать эту хитрую таблицу связей?
2) Или свойства моделей более целесообразно хранить отдельно для каждой модели ? Со своей таблицей связей?
у меня в эту БД добавилось еще пару сущностей, а также - многоязычность...
прошу подсказать по языкам:
добавил я модель Lang,
но язык оказывает влияние на все сущности проекта,
примерно так:
1) книга может быть написана на одном языке, а издана на 3-х,
2) у нее не меняется: автор, категория и жанр;
3) могут быть другие: издатель, тэги, имена и значения свойств;
как эту кучу-малу отразить в таблицах? что с чем связать?
прошу подсказать по языкам:
добавил я модель Lang,
но язык оказывает влияние на все сущности проекта,
примерно так:
1) книга может быть написана на одном языке, а издана на 3-х,
2) у нее не меняется: автор, категория и жанр;
3) могут быть другие: издатель, тэги, имена и значения свойств;
как эту кучу-малу отразить в таблицах? что с чем связать?
M
Так выплаты на банковские счета, а не на данные карт
A
а как ты закидываешь на карту?
M
Твоих данных нет в паблике на сайте, чтобы привлечь к ответственности ? Требуй у начальства фото бумаги с приказом что делать и подписью-печатью - и делай что скажут ) Ну или мейл хотя бы.
M
Чтобы начальство не смогло на тебя всё спихнуть, когда их за жабры возьмут