ты явно про multi_curl в газле спрашиваешь)

ой не

как там тот простенький http клиент назывался

curl

nope

?

curl + bash

Пойдёть

ой не

там тред был про замену постмана и альтернативные ему клиенты

Ребят, есть задача разделить данные компаний-клиентов друг от друга (для секьюрности). Из трех способов, которые нашел: 1. размещение данных компаний в отдельных БД 2. размещение данных компаний в одной БД, но в разных schema 3. размещение все в одной БД, но в таблицы с данными компаний добавить колонку company_id и по ней фильтровать. Третий вариант сразу отбрасываем. У кого-то был опыт работа с 1 или 2 вариантом, на что стоит обратить внимание, с какими проблема сталкивались, сохранность данных. Буду очень благодарен! если что, можно в личку, чтобы не засорять чатик

там тред был про замену постмана и альтернативные ему клиенты

не консольный, но insomnia мне нравится - именно вместо постмана

а как последние 2 варианта относятся к безопасности?

ИМХО все три варианта никак не влияют на безопасность

так-то да, но первый хотя бы иллюзию даёт. Но все явки и пароли всё равно в 1 месте есть

Если приложение имеет креды для доступа в любую из БД одновременно – всё равно

А в чём проявится "секьюрность" в разделении?

Понял. Если отбросить вопрос секьюрности и принять во внимание требование к разделению данных?

No.3 winner!

ой дай бог памяти, который консольный @fes0r от него тащился еще ыы

ты про httpie?

ты про httpie?

+

А в чём проявится "секьюрность" в разделении?

Админ с доступом к определенной БД не будет видеть данных другой компании

В плане сохранности данных, как мне кажется, проще держать разыне БД.

Админ с доступом к определенной БД не будет видеть данных другой компании

Что за дикованный админ, шарящий внутрях БД??? или вы к приложению предоставляете еще графическую морду БД?

Что за дикованный админ, шарящий внутрях БД??? или вы к приложению предоставляете еще графическую морду БД?

Не предоставляем. Клиент может потребовать прямой доступ к БД со своими данными. Но менеджер больше сетует на "секьюрность"

Отдавайте дамп только их данных

Просто как-то не айс смотрится ситуация, что клиент бродит по табличкам.

Не предоставляем. Клиент может потребовать прямой доступ к БД со своими данными. Но менеджер больше сетует на "секьюрность"

Ого, ну это уже другая постановка вопроса.

Просто как-то не айс смотрится ситуация, что клиент бродит по табличкам.

Согласен. Но в плане разработки, поддержки и использования, какой вариант лучше подходит для разделения данных?

Если реально нужно клиенту давать доступ в БД – то строго каждый инстал на отдельный сервер/VDS/контейнер.

Зависит от специфики проекта, но если есть возможность хранить всё в одной БД и отделаться столбцом – это лучше всего, ИМХО. Подумай, как ты будешь накатывать 30 миграций одновременно. Или как агрегировать данные разных клиентов для вашей внутренней статистики

В данный момент, так получается, что есть данные (контент и таблицы), которые могут шариться между клиентами. Но у некоторых клиентов этот контент особенный, и должен принадлежать только им.

Зависит от специфики проекта, но если есть возможность хранить всё в одной БД и отделаться столбцом – это лучше всего, ИМХО. Подумай, как ты будешь накатывать 30 миграций одновременно. Или как агрегировать данные разных клиентов для вашей внутренней статистики

Ад дубликтов :company_name табличек!

Зависит от специфики проекта, но если есть возможность хранить всё в одной БД и отделаться столбцом – это лучше всего, ИМХО. Подумай, как ты будешь накатывать 30 миграций одновременно. Или как агрегировать данные разных клиентов для вашей внутренней статистики

Если одна БД и столбец - то в плане бекапов не будет проблем?

Ад дубликтов :company_name табличек!

типа таблицы с префиксом компании?

типа таблицы с префиксом компании?

Хотите 7 кругов ада, то попробуйте

Хотите 7 кругов ада, то попробуйте

Соглашусь

ты про httpie?

О, прикольно, дякую

Если одна БД и столбец - то в плане бекапов не будет проблем?

А какие проблемы тебе кажутся вероятными?

А какие проблемы тебе кажутся вероятными?

Нет тут никаких проблем, только светлое будущее

Шардинг где ключ это компания?

А какие проблемы тебе кажутся вероятными?

Случайное удаление данных, неверная запись, восстановление данных. К сожалению, опыта у меня не так много в этом деле, но интуиция подсказывает, что все данные пихать в одну таблицу не лучший вариант. Но это только интуиция))

Ад дубликтов :company_name табличек!

а если делить на разные schema?

По поводу восстановления данных: если что-то произойдет с одной бд, то при бекапе данные всех клиентов будут возвращены в точку "бекапа"

Это по поводу хранения в одной бд все.

а если делить на разные schema?

Яйца те же, вид сбоку. Не придумывайте себе проблем. У вас уже озвучены бизнес-требования от заказчика? Он говорит, что мы на 100500% хотим, что наши данные лежали отдельной стопкой?

Яйца те же, вид сбоку. Не придумывайте себе проблем. У вас уже озвучены бизнес-требования от заказчика? Он говорит, что мы на 100500% хотим, что наши данные лежали отдельной стопкой?

нет, не на 100500, это их мнение по поводу данных. У меня задача ресерча и выбора оптимального. Я думаю, надо сильнее их потрясти в этом плане. Но что бы не было выбрано, в случае жопо-боли - она будет у меня)))

Поэтому я хочу и бизнес подстраховать, и себя

Поэтому я хочу и бизнес подстраховать, и себя

Тогда колонка company_id - лучшее решение

Можно для каждой компании view создавать и давать доступы только к ним

Можно для каждой компании view создавать и давать доступы только к ним

в случае размещения всех данных в одной бд и таблицах неплохой вариант

Можно для каждой компании view создавать и давать доступы только к ним

Ну есть ещё row based security

друзья, нужна помощь

долго не могли поставить сайт на хостинг

студия у себя в локалхосте сайт запилила, и теперь сайт сам обращаеться в бд локалхоста

как можно сменить?

laravel

.env

как вы запилили и не знаете как сменить О_о

студия сделала сайт

ERROR: S client not available

.env

где именно?

структуру проекта скинь

как можно сменить?

студию или ларавель?

студию или ларавель?

))))

пути в ларавель уже.

какие пути?

наркоман

там кодер фигачил в локалхосте, показали нам

и сейчас не можем поставить на сервер

Потому что пути ведут на локалхост)

вутифак

поищи по проекту по localhost/127.0.0.1

да вот, хитрые узбеки)

найдешь где захардкодил

да вот, хитрые узбеки)

судя по описанию не хитрые а как раз наоборот

узбеские технологии

только исключи папку vendor

только исключи папку vendor

За что она отвечает?

и ноду

ну это сторонние библиотеки для проекта, там он не может захаркодить локалхост

если у него конечно не своя либа для подключения :D

ох какая пятница будет)

я думаю поиском найдешь

А кто ньюрелик использует активно и кастомно. Интересует, например, как мне посчитать время некой операции, которая начинается в одной транзакции, а кончается в другой…

Ребята, подскажите плиз актуальную книгу или ресурс для начинающих в php. Уровень самообучения у человека - pascal в универе, основы ассемблера на практике

Ребята, подскажите плиз актуальную книгу или ресурс для начинающих в php. Уровень самообучения у человека - pascal в универе, основы ассемблера на практике

Из описания чата: https://gist.github.com/mkusher/711bd46f0b62fbae851182e6fb3b1839

Из описания чата: https://gist.github.com/mkusher/711bd46f0b62fbae851182e6fb3b1839

спасибо, не заглядывал туда

Если уровень английского от Pre Intermediate и выше - я бы рекомендовала видеокасты от laracasts. Просто и понятно объясняют, все хорошо структурированно, плавный переход от простого к более сложному